Proposal: splitting the network package
Michael Snoyman
michael at snoyman.com
Thu Jan 31 15:01:47 CET 2013
On Thu, Jan 31, 2013 at 3:28 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> Michael Snoyman <michael at snoyman.com> writes:
>
>
> [...]
>
> > * 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.
>
> Alas, this causes some of the conditional-API issues mentioned in [1],
> specifically the following situation:
>
> Say, I have a package which specifies only its dependancy on
> 'network-uri' (but not 'network') for its 'Network.URI' module, then the
> package compilation breaks depending on the actual version of the
> 'network' package linked against.
>
>
>
> [1]: http://www.haskell.org/pipermail/libraries/2012-November/018750.html
>
That's true, but I don't think we have *any* means at our disposal of
creating a migration plan that has zero impact on users. The reason I
suggested my approach is that the only change users would need to make is
to add network-uri to their dependency list. You're correct that it's
possible that a user could depend exclusively on network-uri and thereby
cause trouble for users of the older network package, but I would argue
that's an acceptable tradeoff in this case.
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130131/bfc27f27/attachment.htm>
More information about the Libraries
mailing list