Splitting Network.URI from the network package

[Michael Snoyman]

I see no reason *not* to include those in network-uri itself (I've actually
given some thought to that), especially given that that it wouldn't be
adding any new dependencies (network-uri will depend on parsec, which
already depends on bytestring and text). However, I'd recommend adding
those in a post-3.0 release, for two reasons:

1. I think as a general policy, package splitting/merging should not be
accompanied by any other API changes, as that can be confusing for users.
2. Adding a new module like Network.URI.Text would not be a breaking
change, so it won't cause any new upgrade issues in the future.

As far as implementation of such a library, we have plenty of good
questions that come up (should we introduces an attoparsec dep here? should
one of the implementations be the canonical one and the others just
wrappers around it?), but I'd rather address those after this proposal
comes to an end and we have network-uri as its own entity.


On Mon, Aug 4, 2014 at 6:56 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> while we're doing breaking changes, would adding bytestring.char and text
> support to a split out network-uri be in scope. OR should those be in their
> own wee packages?
>
>
> On Sun, Aug 3, 2014 at 10:55 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>
>> Hi,
>>
>> > This was brought up last year[1], and I'd like to bring it up again,
>> based
>> > on a recent issue I was working through with a user[2]. I realize that
>> this
>> > is a breaking change, but:
>>
>> +1
>>
>> > 1. Create a new package, network-uri, version 2.5.0.0, which exposes no
>> > modules and has an upper bound `network < 2.6.
>>
>> Yes, I think that we agreed with the package name of "network-uri".
>>
>> > 2. Create a second release of network-uri, version 3.0.0.0, which
>> provides
>> > the Network.URI module verbatim as provided by the network package
>> today,
>> > and has a lower bound `network >= 3.0`.
>> > 3. Release network version 3.0.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.
>> >
>> > I don't remember how the discussion went last time, but I seem to
>> remember
>> > general consensus. I'd like to set a discussion period of two weeks
>> (August
>> > 15).
>>
>> The consensus was to separate the network-uri package from the network
>> package. We did not reach how to do it. But I think you should put it
>> forward because we should not repeat the plateau again.
>>
>> --Kazu
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> 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/20140804/bd954f03/attachment-0001.html>