Re: Splitting Network.URI from the network package

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

...

wrote:

...

On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman 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