Splitting Network.URI from the network package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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 :) ).


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Michael Snoyman



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
Sure, lets see what other people say. So far Duncan and I are in favor of (1), all things considered. I don't know what Edward thinks now when Duncan has clarified that flags no longer (in cabal 1.18 and 1.20) longer add extra backtracking.


On Wed, Aug 13, 2014 at 2:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Graham Klyne-2
In reply to this post by Michael Snoyman
On 13/08/2014 13:02, Michael Snoyman wrote:

>> 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.

Hmmm... there are reasonable uses of URIs (e.g. in on-disk XML and RDF
processing) that do not necessarily require use of networking.  These may be a
minority, but I think they're not so rare.

Also, my experience in other languages is that one may work with a web
application framework (via something like WSGI), there can lots of URI handling
code without any direct use of networking.  Also, I do a lot of testing of URI
handling code separately from any networking.

I think removing the URI handling dependency on networking would be a Good Thing.

#g

(developer of a past version of network-uri.)

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Christian Maeder-2
I would prefer option 1, too, that is keep network-uri independent from
network.

(I also think, the version number for network-uri could start at 1.0.)

network-uri should be preferred over other "uri" packages [1]

Cheers Christian

[1] http://hackage.haskell.org/packages/search?terms=uri

Am 14.08.2014 15:49, schrieb Graham Klyne:

> On 13/08/2014 13:02, Michael Snoyman wrote:
>>> 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.
>
> Hmmm... there are reasonable uses of URIs (e.g. in on-disk XML and RDF
> processing) that do not necessarily require use of networking.  These
> may be a minority, but I think they're not so rare.
>
> Also, my experience in other languages is that one may work with a web
> application framework (via something like WSGI), there can lots of URI
> handling code without any direct use of networking.  Also, I do a lot of
> testing of URI handling code separately from any networking.
>
> I think removing the URI handling dependency on networking would be a
> Good Thing.
>
> #g
>
> (developer of a past version of network-uri.)
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Herbert Valerio Riedel
On 2014-08-15 at 10:35:54 +0200, Christian Maeder wrote:

[...]

> network-uri should be preferred over other "uri" packages [1]

Tbh, I don't like the current Network.URI API, as it's heavily 'String'
based. If you have process/store a lot of URIs you incur a measurable
overhead.

Fwiw, this has been noticed in the past:

 - http://www.haskell.org/pipermail/haskell-cafe/2012-March/100004.html

 - http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/18761


However, I am not aware of any Network.URI replacement based on 'Text'
or 'ByteString' yet. So far I've just coded up minimal URL parsers that
worked on a small subset of the URI grammer when I wanted something more
efficient.

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Michael Snoyman
In reply to this post by Michael Snoyman



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
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 <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Carter Schonwald
In reply to this post by Herbert Valerio Riedel
+1 to this. Evolving the lib to support text too would be high roi.  

I'd be happy to help maintain URI if that sort of change / evolution was in scope for how to evolve it.  

On Friday, August 15, 2014, Herbert Valerio Riedel <[hidden email]> wrote:
On 2014-08-15 at 10:35:54 +0200, Christian Maeder wrote:

[...]

> network-uri should be preferred over other "uri" packages [1]

Tbh, I don't like the current Network.URI API, as it's heavily 'String'
based. If you have process/store a lot of URIs you incur a measurable
overhead.

Fwiw, this has been noticed in the past:

 - http://www.haskell.org/pipermail/haskell-cafe/2012-March/100004.html

 - http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/18761


However, I am not aware of any Network.URI replacement based on 'Text'
or 'ByteString' yet. So far I've just coded up minimal URL parsers that
worked on a small subset of the URI grammer when I wanted something more
efficient.

Cheers,
  hvr
_______________________________________________
Libraries mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Libraries@haskell.org&#39;)">Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

MightyByte
Soostone just started working on a uri-bytestring package.  It's not
quite ready for hackage yet, but it is pretty useable.

https://github.com/Soostone/uri-bytestring

On Fri, Aug 15, 2014 at 4:11 PM, Carter Schonwald
<[hidden email]> wrote:

> +1 to this. Evolving the lib to support text too would be high roi.
>
> I'd be happy to help maintain URI if that sort of change / evolution was in
> scope for how to evolve it.
>
> On Friday, August 15, 2014, Herbert Valerio Riedel <[hidden email]> wrote:
>>
>> On 2014-08-15 at 10:35:54 +0200, Christian Maeder wrote:
>>
>> [...]
>>
>> > network-uri should be preferred over other "uri" packages [1]
>>
>> Tbh, I don't like the current Network.URI API, as it's heavily 'String'
>> based. If you have process/store a lot of URIs you incur a measurable
>> overhead.
>>
>> Fwiw, this has been noticed in the past:
>>
>>  - http://www.haskell.org/pipermail/haskell-cafe/2012-March/100004.html
>>
>>  - http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/18761
>>
>>
>> However, I am not aware of any Network.URI replacement based on 'Text'
>> or 'ByteString' yet. So far I've just coded up minimal URL parsers that
>> worked on a small subset of the URI grammer when I wanted something more
>> efficient.
>>
>> Cheers,
>>   hvr
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
In reply to this post by Johan Tibell-2
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 <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Edward Kmett-2
In reply to this post by Duncan Coutts-4
On Wed, Aug 13, 2014 at 7:33 AM, Duncan Coutts <[hidden email]> wrote:
So it's true that using flags here is the standard solution (e.g. as
was used with the base split for a few years), so many (but not all)
users know this already.

I should also note (Andres: please correct me if I'm wrong) that as of
cabal-install 1.20, the cost in terms of backtracking for flags like
these is now quite small because choosing them is deferred as late as
possible. Edward: this should solve your problem with flags with
transformers, at least once 1.20 is widely used. It'd be great if you
could check that this is the case.

Right now I'm stuck supporting people who use some very old cabal installs, so it'll be a long long time in my case. :)

I find myself a bit gunshy here as every time I use a flag I get a complaint from somewhere. 

The experience trying and failing to fix the use of flags in transformers-compat has left me personally somewhat sworn off non manual flags for now. AFAIK, we didn't actually fix the bug there with the first try or two, but Andres may have managed to fix it after I gave up. There is was admittedly a different issue with the backtracker missing a case.

I'm happy to go along with the plan, but I confess I suspect it'll lead to at least one bug report somewhere, and if it doesn't I'll just enjoy the pleasant surprise. =)

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
In reply to this post by Johan Tibell-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Michael Snoyman
Awesome, thanks Johan!


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



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Carter Schonwald
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 <[hidden email]> wrote:
Awesome, thanks Johan!


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



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Carter Schonwald
Huh, Aristid seems to have hit stuff breaking already ! 




On Sat, Aug 16, 2014 at 1:35 PM, Carter Schonwald <[hidden email]> 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 <[hidden email]> wrote:
Awesome, thanks Johan!


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



On Wed, Aug 13, 2014 at 3:02 PM, Michael Snoyman <[hidden email]> wrote:



On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman <[hidden email]> wrote:
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Edward Z. Yang
In reply to this post by Michael Snoyman
Hello all,

I'd like to report some more subtle breakage with respect to this
split regarding packages which depend on just network-uri, but
not network itself.  The issue is reported here:
https://github.com/haskell/cabal/issues/2063

I think the workaround is to add a "bogus" dependency on network
if you use the flags.

Cheers,
Edward

Excerpts from Michael Snoyman's message of 2014-08-01 12:31:13 +0100:

> 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. It's a minor breaking change: you simply need to add an extra package to
> your build-depends.
> 2. The problems caused by having a parsec dependency in network can be
> severe, especially for new users (I'll describe the details after the
> proposal).
>
> Concretely, I believe we should do the following:
>
> 1. Create a new package, network-uri, version 2.5.0.0, which exposes no
> modules and has an upper bound `network < 2.6.
> 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).
>
> ## Motivation
>
> To give a concrete example of why this problem is severe, consider the
> following data:
>
> * The network package is a pain to install on Windows for most users
> (especially new users), since it requires msys.
> * Most Windows users therefore install the Haskell Platform, avoiding the
> msys dependency.
> * The current release of HP installs text version 0.11.3.1. text is a
> dependency of parsec, and parsec is a dependency of network. Therefore, you
> can't build against a new version of text *and* use the network package
> without recompiling network, which as I mentioned is difficult.
> * A number of popular packages depend on newer versions of text. For
> example, since 0.8.0.0, aeson requires text version 1.1.0.0 or later. as
> does attoparsec since version 0.12.0.0.
>
> [1] http://www.haskell.org/pipermail/libraries/2013-January/019234.html
> [2] https://groups.google.com/d/msg/yesodweb/auk2vByXgO8/lUZ9oanKyMwJ
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Edward Z. Yang
To be clear, I suggest we change the default recommended build-depends
text from:

 library
   -- ...
   if flag(network-uri)
     build-depends: network-uri >= 2.6
   else
     build-depends: network < 2.6

to

 library
   -- ...
   if flag(network-uri)
     build-depends: network-uri >= 2.6, network >= 2.6
   else
     build-depends: network < 2.6

Cheers,
Edward

Excerpts from Edward Z. Yang's message of 2014-08-27 15:15:27 +0100:

> Hello all,
>
> I'd like to report some more subtle breakage with respect to this
> split regarding packages which depend on just network-uri, but
> not network itself.  The issue is reported here:
> https://github.com/haskell/cabal/issues/2063
>
> I think the workaround is to add a "bogus" dependency on network
> if you use the flags.
>
> Cheers,
> Edward
>
> Excerpts from Michael Snoyman's message of 2014-08-01 12:31:13 +0100:
> > 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. It's a minor breaking change: you simply need to add an extra package to
> > your build-depends.
> > 2. The problems caused by having a parsec dependency in network can be
> > severe, especially for new users (I'll describe the details after the
> > proposal).
> >
> > Concretely, I believe we should do the following:
> >
> > 1. Create a new package, network-uri, version 2.5.0.0, which exposes no
> > modules and has an upper bound `network < 2.6.
> > 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).
> >
> > ## Motivation
> >
> > To give a concrete example of why this problem is severe, consider the
> > following data:
> >
> > * The network package is a pain to install on Windows for most users
> > (especially new users), since it requires msys.
> > * Most Windows users therefore install the Haskell Platform, avoiding the
> > msys dependency.
> > * The current release of HP installs text version 0.11.3.1. text is a
> > dependency of parsec, and parsec is a dependency of network. Therefore, you
> > can't build against a new version of text *and* use the network package
> > without recompiling network, which as I mentioned is difficult.
> > * A number of popular packages depend on newer versions of text. For
> > example, since 0.8.0.0, aeson requires text version 1.1.0.0 or later. as
> > does attoparsec since version 0.12.0.0.
> >
> > [1] http://www.haskell.org/pipermail/libraries/2013-January/019234.html
> > [2] https://groups.google.com/d/msg/yesodweb/auk2vByXgO8/lUZ9oanKyMwJ
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Network.URI from the network package

Johan Tibell-2
I'd like to confirm that this is due to the solver and not how the sandbox invokes it first.


On Wed, Aug 27, 2014 at 4:23 PM, Edward Z. Yang <[hidden email]> wrote:
To be clear, I suggest we change the default recommended build-depends
text from:

 library
   -- ...
   if flag(network-uri)
     build-depends: network-uri >= 2.6
   else
     build-depends: network < 2.6

to

 library
   -- ...
   if flag(network-uri)
     build-depends: network-uri >= 2.6, network >= 2.6
   else
     build-depends: network < 2.6

Cheers,
Edward

Excerpts from Edward Z. Yang's message of 2014-08-27 15:15:27 +0100:
> Hello all,
>
> I'd like to report some more subtle breakage with respect to this
> split regarding packages which depend on just network-uri, but
> not network itself.  The issue is reported here:
> https://github.com/haskell/cabal/issues/2063
>
> I think the workaround is to add a "bogus" dependency on network
> if you use the flags.
>
> Cheers,
> Edward
>
> Excerpts from Michael Snoyman's message of 2014-08-01 12:31:13 +0100:
> > 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. It's a minor breaking change: you simply need to add an extra package to
> > your build-depends.
> > 2. The problems caused by having a parsec dependency in network can be
> > severe, especially for new users (I'll describe the details after the
> > proposal).
> >
> > Concretely, I believe we should do the following:
> >
> > 1. Create a new package, network-uri, version 2.5.0.0, which exposes no
> > modules and has an upper bound `network < 2.6.
> > 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).
> >
> > ## Motivation
> >
> > To give a concrete example of why this problem is severe, consider the
> > following data:
> >
> > * The network package is a pain to install on Windows for most users
> > (especially new users), since it requires msys.
> > * Most Windows users therefore install the Haskell Platform, avoiding the
> > msys dependency.
> > * The current release of HP installs text version 0.11.3.1. text is a
> > dependency of parsec, and parsec is a dependency of network. Therefore, you
> > can't build against a new version of text *and* use the network package
> > without recompiling network, which as I mentioned is difficult.
> > * A number of popular packages depend on newer versions of text. For
> > example, since 0.8.0.0, aeson requires text version 1.1.0.0 or later. as
> > does attoparsec since version 0.12.0.0.
> >
> > [1] http://www.haskell.org/pipermail/libraries/2013-January/019234.html
> > [2] https://groups.google.com/d/msg/yesodweb/auk2vByXgO8/lUZ9oanKyMwJ
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123