Splitting Network.URI from the network package
Johan Tibell
johan.tibell at gmail.com
Fri Aug 15 10:56:06 UTC 2014
Hi Michael,
I will do the required changes (split, add docs, etc) and put the new
package under https://github.com/haskell/network-uri (for now).
It would be great to have a new maintainer, under the condition that the
new maintainer recognizes that
* Network.URI has been around for a long time and lots of users depend on
it, so please don't break backwards compatibility without some serious
thought and
* the package is a part of the HP (by virtue of network being apart and we
don't want to remove a module without due process), so the maintainer will
need to adhere to the HP rules (e.g. don't add new deps that are not part
of the HP).
I will try to do the split in the next few days, but I have visitors so it
might take a bit longer.
-- Johan
On Fri, Aug 15, 2014 at 12:45 PM, Michael Snoyman <michael at snoyman.com>
wrote:
>
>
>
> 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/01cc8630/attachment.html>
More information about the Libraries
mailing list