Splitting Network.URI from the network package

Carter Schonwald carter.schonwald at gmail.com
Sat Aug 16 19:37:40 UTC 2014


Huh, Aristid seems to have hit stuff breaking already !
https://twitter.com/aristidb/status/500716130458431488




On Sat, Aug 16, 2014 at 1:35 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> same!
>
> I'd be willing to be a co-maintainer with 1-2+ other folks
>
>
> On Sat, Aug 16, 2014 at 1:18 PM, Michael Snoyman <michael at snoyman.com>
> wrote:
>
>> Awesome, thanks Johan!
>>
>>
>> On Sat, Aug 16, 2014 at 7:49 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>
>>> OK. The split is done and both packages are now on Hackage.
>>>
>>> If someone is interested in maintaining the network-uri package (under
>>> the HP constraints), please let me know and I can add you to the GitHub
>>> repo on github.com/haskell/network-uri. I've set up a travis-ci build
>>> for the package as well.
>>>
>>>
>>> On Sat, Aug 16, 2014 at 6:08 PM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>>
>>>> The network-uri repo lives at https://github.com/haskell/network-uri
>>>> for now.
>>>>
>>>>
>>>> On Sat, Aug 16, 2014 at 5:51 PM, Johan Tibell <johan.tibell at gmail.com>
>>>> wrote:
>>>>
>>>>> The network master branch now has the changes I intend for network-2.6
>>>>> (plus some internal clean-up).
>>>>>
>>>>>
>>>>> On Fri, Aug 15, 2014 at 12:56 PM, Johan Tibell <johan.tibell at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140816/7eee0b30/attachment-0001.html>


More information about the Libraries mailing list