Splitting Network.URI from the network package

[Johan Tibell]

Sure, lets see what other people say. So far Duncan and I are in favor of
(1), all things considered. I don't know what Edward thinks now when Duncan
has clarified that flags no longer (in cabal 1.18 and 1.20) longer add
extra backtracking.


On Wed, Aug 13, 2014 at 2: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140813/3f0413cf/attachment.html>