Proposal: splitting the network package

[Gregory Collins]

Also "network" is where we want the network stuff to live, not
"network-socket".


On Wed, Feb 6, 2013 at 5:49 PM, Michael Snoyman <michael at snoyman.com> wrote:

>
>
>
> On Wed, Feb 6, 2013 at 11:22 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:
>
>> 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
>>
>
> Well, that approach requires the creation of an extra package and
> ultimately deprecating the main package, forcing users to have to learn
> about a new package. I'd rather not have to rename a package just because I
> want to split off one piece of functionality to a separate package.
>
> Michael
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130206/d5a2ddf1/attachment.htm>