Re: Splitting Network.URI from the network package

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@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 wrote:

...

Awesome, thanks Johan!

On Sat, Aug 16, 2014 at 7:49 PM, Johan Tibell 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 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 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

...

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@snoyman.com> wrote:

> > > > On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman < > michael@snoyman.com> wrote: > >> >> >> >> On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell < >> johan.tibell@gmail.com> wrote: >> >>> On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman < >>> michael@snoyman.com> wrote: >>> >>>> On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell < >>>> johan.tibell@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries