Proposal: splitting the network package
Herbert Valerio Riedel
hvr at gnu.org
Wed Feb 6 10:22:51 CET 2013
Michael Snoyman <michael at snoyman.com> writes:
[...]
>> An alternative would be to split the "network" package into
>> "network-uri" and "network-socket". Users of network-uri would have
>> to switch to network-socket as well. However, the types of "network"
>> and "network-socket" would be incompatible unless the
>> "network-socket" package re-exports the modules from "network" or
>> vice versa.
>>
>> E.g. could we put this into the "network" package:
>>
>> {-# LANGUAGE PackageImports #-}
>> module Network.Socket ( module S ) where
>>
>> import qualified "network-socket" Network.Socket as S
>>
>> ?
[...]
> Recently, we have a similar situation with http-conduit. Based on that, I'd
> recommend going for a conditional export situation.
>
> * Release a new version of network (1.5) that does not include the
> Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
> * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
> * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.
[...]
What's the actual downside with Henning's proposed package splitting
method?
I.e., the new transitional `network` package wouldn't have any visible
changes in its exports (and so wouldn't require any major version bump),
but its (re-exported) implementation gets moved into two new packages,
`network-uri` and `network-socket`.
So users of `network` which don't want to or can't switch yet to the new
`network-{uri,socket}` packages can remain on `network` for the time
being.
After an appropriate deprecation cycle, the `network` packages doesn't
get updated anymore to support newer major package versions of
`network-{uri,socket}` which may then start to break compatibility
significantly at the type-level.
To me, this seems to avoid breaking the PVP contract, as well as
avoiding requiring clients of `network` to introduce
conditional-compilation directives. Moreover, it wouldn't require client
packages to switch to new packages right away, while sharing the data
types of the new `network-{socket,uri}` packages.
Am I overlooking something?
cheers,
hvr
More information about the Libraries
mailing list