Splitting Network.URI from the network package

[Michael Snoyman]

On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <michael at snoyman.com>
wrote:

>
>
>
> On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>>
>>> On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>>
>>  *Options 2: Users of Network.URI depend on both network and a specially
>>>> crafted network-uri*
>>>>
>>>
>>>>
>>>>> ...
>>>>
>>>>
>>>  Cons:
>>>>
>>>>    - network-uri has a false dependency on network (i.e. it doesn't
>>>>    actually need that package).
>>>>    - You can't build against a new version of text *and* use the
>>>>       network-uri package (this is the current problem we have with network in
>>>>       the problem description).
>>>>
>>>>  Can you clarify this point? I would imagine that network will no
>>> longer have *any* dependency on text, so I don't see where this comes from.
>>>
>>
>> My apologies. Let me clarify. If the user doesn't already have a version
>> of network installed (e.g. via the HP), then building network is required
>> to build network-uri. This probably isn't a problem on Windows, if we
>> assume users already have an appropriate version of network through the HP.
>> It might be an inconvenience (e.g. longer build times) for users who don't
>> use the HP but still want to build network-uri (e.g for the maintainer of
>> network-uri :) ).
>>
>>
> Thanks for the clarifications Duncan and Johan. Yes, we should add a con
> to the option 2 that usage of network-uri will require network to be
> available. I'd consider this a relatively low-impact con, since I highly
> doubt there are many people out there who will want to use Network.URI but
> not also want to use network- at least transitively.
>
> Even after the arguments from Duncan and Johan, I still would prefer going
> with option 2, because (1) I don't feel confident yet that all flag-related
> issues in the dependency solver have been fixed (up until just two weeks
> ago I was still answering user questions about those bugs), and (2) my
> experience with the flag approach was that it was very tedious to work
> with, and I remember seeing a lot of confusion among other packages as to
> the right way to specify dependencies.
>
> I still think that either option 1 or option 2 are better than the current
> status quo, so I'd rather not let this issue become a sticking point in the
> proposal. I'd say let's take a vote on option 1 or 2, and continue with the
> discussion deadline for this proposal (which seems to have unanimous
> support) of this Friday. Any objection?
>
> Michael
>

Given the lack of objections, I think it's fair to call this issue decided
in favor of the original proposal, with the modification under "option 1"
that Johan described. To summarize:

1. Create a new package, network-uri, version 2.6.0.0, which provides the
Network.URI module verbatim as provided by the network package today, and
has no dependency at all on network.
2. Release network version 2.6.0.0, with no changes from the currently
released version, except that (a) no Network.URI module is provided, and
(b) there is no parsec dependency.

Presumably, we will also add some documentation to the network and
network-uri cabal files with instructions on how to depend on the
Network.URI module.

Johan: given that you're the current maintainer of network, how would you
like to proceed on implementing this? Do you want to do so yourself, or do
you want a pull request? And regarding network-uri: do you want to remain
maintainer of it, or should I (or someone else) take it over?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140815/8251554a/attachment-0001.html>