Proposal: Changes to the PVP

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

Re: Proposal: Changes to the PVP

Ganesh Sittampalam
On 10/04/2014 07:30, Ivan Lazar Miljenovic wrote:

> On 10 April 2014 16:19, Ganesh Sittampalam <[hidden email]> wrote:
>> On 10/04/2014 05:30, Michael Snoyman wrote:
>>
>>> * Module reexports leaking from transitive dependencies.
>>
>> Shouldn't we just be saying "don't reexport entire modules from other
>> packages"? Is there a scenario where this is useful? One scenario I can
>> see is perhaps inside groups of packages maintained by the same author
>> or in the same source tree, but then the author can bump all the
>> packages in sync if necessary.
>
> Re-exporting modules like Control.Applicative for parsing libraries?

I'd expect users to import Control.Applicative directly in that case,
but I haven't surveyed what existing parsing libraries do in practice.

Thinking about this more, as a user of a package Y I think I'd be
confused if it re-exported symbols that are defined in package X at all
even if done with an explicit export list rather than an entire module.

It would take some effort to check if they are actually the same as
those in X and therefore won't cause clashes if I also import them from
X directly for other purposes.

It would be interesting to check how common this is, I guess by scanning
hackage.

Cheers,

Ganesh

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

Re: Proposal: Changes to the PVP

Johan Tibell-2
In reply to this post by Michael Snoyman
On Thu, Apr 10, 2014 at 8:24 AM, Michael Snoyman <[hidden email]> wrote:
On Thu, Apr 10, 2014 at 9:19 AM, Ganesh Sittampalam <[hidden email]> wrote:
On 10/04/2014 05:30, Michael Snoyman wrote:> I think it's obvious that no amendment to the text of the PVP will be
> accepted by this list, so educating users that they're using their tools
> incorrectly clearly won't be happening on that page.

Didn't Johan get an amendment agreed a few weeks ago? I think your
current amendments will have difficulty because they are based on
premises that many people disagree with, but that doesn't mean that no
amendments at all are possible.

I should have clarified: no amendment that points out flaws in the PVP. My premise is simple: the PVP is a useful tool, but does not address all cases. Since people seem to mistakenly believe that it will protect them from all build problems, the text should be amended to make that clear. Every attempt I've made to come up with text that is acceptable to this list has been met with resistance. If someone else can come up with a modification that is acceptable, great. But I'm not going to continue trying, and will instead try to inform people through other channels that they need to use something more than the PVP if they want reproducible builds.

There are already text describing flaws in the PVP (e.g. the aforementioned instance leak and issues with adding new modules). We should add something about module exports.

What the PVP page doesn't address, and I don't think it should address, are orthogonal issues i.e. issues related to reproducible builds*.

* Here using the meaning: building using exactly the same bits.


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

Re: Proposal: Changes to the PVP

Herbert Valerio Riedel
In reply to this post by Ganesh Sittampalam
On 2014-04-10 at 08:19:10 +0200, Ganesh Sittampalam wrote:
> On 10/04/2014 05:30, Michael Snoyman wrote:
>
>> * Module reexports leaking from transitive dependencies.
>
> Shouldn't we just be saying "don't reexport entire modules from other
> packages"? Is there a scenario where this is useful? One scenario I can
> see is perhaps inside groups of packages maintained by the same author
> or in the same source tree, but then the author can bump all the
> packages in sync if necessary.

Btw, if one does re-export entire modules (w/o filtering via
import/export lists), you simply have to put an upper bound at the
minor-version level of the package you're re-exporting.

Maybe a note making that more explicit would be sensible (IMO it's
actually just an implication of the current PVP but making it more
obvious wouldn't hurt).
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Adam Bergmark-2
In reply to this post by Michael Snoyman
On Thu, Apr 10, 2014 at 6:30 AM, Michael Snoyman <[hidden email]> wrote:

But as has been mentioned elsewhere, the accidental uploads is far worse than it seems at first, since cabal can backtrack and continue using the bad version! If I upload foo-1.0.0.1 that mistakenly says it works with bar 1.1, and then issue a point release foo-1.0.0.2 that puts the upper bound back on bar, cabal will no longer get any PVP upper bound benefits, since it will simply try to use foo-1.0.0.1.



 Isn't this fixed to a large degree by deprecating the bad version on hackage? I also hope the library maintainer would release foo-1.0.0.3 that properly builds with bar 1.1. This can still cause issues, but I think it should be solved with tooling.




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

Re: Proposal: Changes to the PVP

Peter Simons
In reply to this post by Michael Snoyman
Hi Michael,

 > The *additional* tool I recommended (version freezing) is going to be
 > cheap to use [and] has additional benefits not covered by the PVP,
 > which we should be encouraging users to take advantage of anyway.

my understanding is that "version freezing" means to over-specify the
restrictions on build inputs, i.e. to require that dependencies exist in
a specific version instead of any version that lies in a given version
range. If I misunderstood what you mean, then please correct me!

My experience with version freezing (over-specified dependency
restrictions) is that you it invariably leads to a situation where
packages A and B mutually exclude each other because they require
C==1.0.0.1 and C==1.0.0.2, respectively. This might a lesser problem for
developers hacking away in their project-local Cabal sandboxes, but for
people who try to maintain a consistent package set that's used to
distribute binary packages to their users, this is a nightmare, because
our lives become significantly more complicated if we have to keep
several versions of the same packages around -- especially if those
packages are near the root of the dependency tree.

In fact, your habit of doing that has eventually led NixOS to the
development of jailbreak-cabal [1], a tool that automatically removes
all dependency restrictions from a Cabal file to undo the "version
freeze", and I dare say that the vast majority of build problems we run
into while trying to upgrade a package can be solved by running that
tool.

So, if a "version freeze" really is what I think it is, then I can't say
that I like the idea of encouraging other people to pick up that habit.

Just my 2 cents,
Peter

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

Re: Proposal: Changes to the PVP

Greg Weber


On Fri, Apr 11, 2014 at 10:57 AM, Peter Simons <[hidden email]> wrote:
Hi Michael,

 > The *additional* tool I recommended (version freezing) is going to be
 > cheap to use [and] has additional benefits not covered by the PVP,
 > which we should be encouraging users to take advantage of anyway.

my understanding is that "version freezing" means to over-specify the
restrictions on build inputs, i.e. to require that dependencies exist in
a specific version instead of any version that lies in a given version
range. If I misunderstood what you mean, then please correct me!


version freezing is for application developers, not library distributors like yourself.

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

Re: Proposal: Changes to the PVP

Peter Simons
Hi Greg,

 > Version freezing is for application developers, not library
 > distributors like yourself.

distributions ship both libraries and applications, and the applications
are built with the set of libraries available within the distribution,
of course. Because of this, version freezing in applications affects
distributors very much, because we have to include the dependencies in
exactly those versions that the application developer fancied -- instead
of being able to chose from a range of versions that are convenient for
the purposes of the distribution.

I have packaged Haskell libraries and applications in ArchLinux and
NixOS for the last 5+ years, and please believe me when I say that
"version freezing" has caused me a lot of trouble in that time -- so
much that we've developed tools to automatically undo it.

Best regards,
Peter

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

Re: Proposal: Changes to the PVP

Greg Weber
distributing applications compiled from source code (maybe you are referring to XMonad?) is an interesting middle ground where there are pros and cons to freezing. By application developer I really mean someone that is only sharing an application with other team members that are developing the application.


On Fri, Apr 11, 2014 at 12:51 PM, Peter Simons <[hidden email]> wrote:
Hi Greg,

 > Version freezing is for application developers, not library
 > distributors like yourself.

distributions ship both libraries and applications, and the applications
are built with the set of libraries available within the distribution,
of course. Because of this, version freezing in applications affects
distributors very much, because we have to include the dependencies in
exactly those versions that the application developer fancied -- instead
of being able to chose from a range of versions that are convenient for
the purposes of the distribution.

I have packaged Haskell libraries and applications in ArchLinux and
NixOS for the last 5+ years, and please believe me when I say that
"version freezing" has caused me a lot of trouble in that time -- so
much that we've developed tools to automatically undo it.

Best regards,
Peter

_______________________________________________
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: Proposal: Changes to the PVP

Henning Thielemann-4
In reply to this post by Johan Tibell-2
Am 09.04.2014 21:55, schrieb Johan Tibell:

> On Wed, Apr 9, 2014 at 9:22 PM, Michael Snoyman <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     So forget my proposal for the moment, I want to engage in a thought
>     experiment. What does the current PVP say about the following scenarios:
>
>     1. A user is writing an application based on a number of Hackage
>     libraries. He places version bounds following the PVP, e.g. `text >=
>     1.0 && < 1.1, aeson >= 0.7 && < 0.8`.
>          a. Has he done a good enough job of writing his application?
>
>
> That's a kinda vague question. :) Has he made sure that his package will
> continue to build if there are backwards incompatible changes in text or
> aeson? Yes.

With these version bounds he do not need to expect incompatible changes
in "text" or "aeson", he must only be prepared for additions, i.e. he
must import explicitly or with qualification.

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

Re: Proposal: Changes to the PVP

Henning Thielemann-4
In reply to this post by Ganesh Sittampalam
Am 10.04.2014 08:43, schrieb Ganesh Sittampalam:

> Thinking about this more, as a user of a package Y I think I'd be
> confused if it re-exported symbols that are defined in package X at all
> even if done with an explicit export list rather than an entire module.
>
> It would take some effort to check if they are actually the same as
> those in X and therefore won't cause clashes if I also import them from
> X directly for other purposes.

I think we cannot rely on the fact that A.X and B.X identify the same
entity. It may be true today, but may change in future. Thus I would
also not recommend re-exporting single identifiers from other packages.

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