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