Proposal: splitting the network package

Michael Snoyman michael at
Fri Feb 1 07:05:30 CET 2013

On Fri, Feb 1, 2013 at 7:53 AM, Kazu Yamamoto <kazu at> wrote:

> > * 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.
> I don't understand benefits of this plan. Consider another simpler
> plan: we just provide two packages:
>   - "network" without Network.URI
>   - "network-uri" which includes Network.URI only (without the
>     conditionals)
> What is the difference Michael's one and this?
> In other words, what does Michael's one contribute from the backward
> compatibility point of view?
> --Kazu
> _______________________________________________
> Libraries mailing list
> Libraries at

Many users won't be able to upgrade to the new network library immediately.
However, adding an extra dependency on (an essentially empty) network-uri
is perfectly feasible. My approach makes it possible for library authors to
make their code compatible with both network 1.4 and 1.5 with just a single
line change.

If you want to see examples that were more painful from the author
perspective, consider the previous merging of network and
network-bytestring, or the blaze-markup/blaze-html split. Both of them
required adding cabal flags and conditionals to every user package that
wanted to work with both versions, which definitely caused some headaches.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list