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
|

Proposal: Changes to the PVP

Michael Snoyman
I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post.

1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees.

2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.

3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.)

4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).)


_______________________________________________
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

Gregory Collins-3
-1, obviously :)


On Wed, Apr 9, 2014 at 10:47 AM, Michael Snoyman <[hidden email]> wrote:
I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post.

1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees.

2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.

3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.)

4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).)


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




--
Gregory Collins <[hidden email]>

_______________________________________________
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 Michael Snoyman
Am 09.04.2014 10:47, schrieb Michael Snoyman:

> I would like to propose the following changes to the PVP. These are the
> same changes that I recently published on the Yesod blog[1]. For more
> information on the motivations behind these changes, please see that
> blog post.

I see no need to complicate the PVP with distinctions about stable and
unstable, published and unpublished packages. My preferred solution is
to declare lower and upper version bounds in Build-Depends according to
current PVP and ignore these bounds on demand via options that are
passed to cabal-install.

_______________________________________________
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
(1) I would never say no to making something more clear. The goal is currently given in the first few paragraphs of the PVP. Please give the actual text you'd like to see.

The current goal can be summarized as: give a meaning to version numbers. The reason for that goal was problems with unbuildable packages that we experienced prior to the PVP.

I don't see how the PVP as written anywhere suggests that the PVP aspires to provide reproducible builds. It only talks about compatible APIs.

(2) I'm somewhat ambivalent about removing the upper bounds for the 3 packages that are not upgradable (base, template-haskell, and ghc-prim). On one hand removing upper bounds doesn't introduce additional breakages and avoids having maintainers bump bounds on each GHC release* (~yearly), but on the other hand it creates worse error messages**. The solver could tell the user "Your package doesn't work with the version of base you have installed." instead of giving them a potentially confusing compilation error.

* I find it quite disconcerting that we bump the major version of base on every release. We shouldn't make breaking changes to the most core of core libraries on every release! I also note that GHC 7.4.1 seems to have bumped the major version on base even though no breaking change was made: https://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html

** Although Cabal's dependency solver doesn't give the best messages today either. But at least it could be improved.

(3) This is already the case. We just don't encourage authors to do it (as maintaining version information in documentation rather than machine-checkable contracts tends to be hard to maintain.)

-- Johan


_______________________________________________
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

Erik Hesselink
In reply to this post by Michael Snoyman
On Wed, Apr 9, 2014 at 10:47 AM, Michael Snoyman <[hidden email]> wrote:
> I would like to propose the following changes to the PVP. These are the same
> changes that I recently published on the Yesod blog[1]. For more information
> on the motivations behind these changes, please see that blog post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
> reproducible builds of non-published software, but rather to provide for
> more reliable builds of libraries on Hackage. Reproducible builds should be
> handled exclusively through version freezing, the only known technique to
> actually give the necessary guarantees.

I think this would be fine to add. Since part of the PVP talks about
ranges on dependency versions anyway, reproducible build are out the
window from the start. It doesn't hurt to add a sentence or two
mentioning this.

However, checking the current document, the very first paragraph says:

"The goal of a versioning system is to inform clients of a package of
changes to that package that might affect them, and to provide a way
for clients to specify a particular version or range of versions of a
dependency that they are compatible with."

It already seems pretty clear to me.

> 2. Upper bounds should not be included on non-upgradeable packages, such as
> base and template-haskell (are there others?). Alternatively, we should
> establish some accepted upper bound on these packages, e.g. many people
> place base < 5 on their code.

A lot of packages break from upgrades to base and template-haskell. I
think removing the upper bounds here will lead to a lot of confusion,
so I'm -1 on this one.

> 3. We should be distinguishing between mostly-stable packages and unstable
> packages. For a package like text, if you simply import Data.Text (Text,
> pack, reverse), or some other sane subset, there's no need for upper bounds.
> (Note that this doesn't provide a hard-and-fast rule like the current PVP,
> but is rather a matter of discretion. Communication between library authors
> and users (via documentation or other means) would be vital to making this
> work well.)

This sounds too vague to be an actual policy, so -1.

> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries which
> use these packages are free to rely on the guarantees provided by package
> authors when placing upper bounds. (Note that this is very related to point
> (3).)

Isn't this already the case?

Erik
_______________________________________________
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

Simon Marechal
In reply to this post by Johan Tibell-2
On 04/09/2014 11:31 AM, Johan Tibell wrote:
> On one hand removing upper bounds doesn't introduce additional breakages
> and avoids having maintainers bump bounds on each GHC release*
> (~yearly), but on the other hand it creates worse error messages**.

They might be scarier, but I think they are better. A clueless end user
will at least know which package won't build for him, and can alert the
appropriate maintainer.
_______________________________________________
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

Michael Snoyman
In reply to this post by Johan Tibell-2



On Wed, Apr 9, 2014 at 12:31 PM, Johan Tibell <[hidden email]> wrote:
(1) I would never say no to making something more clear. The goal is currently given in the first few paragraphs of the PVP. Please give the actual text you'd like to see.

The current goal can be summarized as: give a meaning to version numbers. The reason for that goal was problems with unbuildable packages that we experienced prior to the PVP.

I don't see how the PVP as written anywhere suggests that the PVP aspires to provide reproducible builds. It only talks about compatible APIs.


Nonetheless, there is definitely confusion. The easiest way to see that is to look at the Reddit discussion of the blog post[1]. For example:

> Which implicitly includes supporting reproducible builds for "non-published software"

There are other examples in that discussion, as well as in the libraries@ discussion. My proposed addition to the PVP itself would be the text:

While PVP compliance makes getting a successful build more likely, it does not try to encourage reproducible builds: builds which use exactly the same dependencies as previous builds. In particular: minor version bumps and changes in transitive dependencies can easily slip in. Reproducible builds are highly recommended for building production executables, and for that, dependency freezing is the only known solution (to be included in cabal-install after version X).

 
(2) I'm somewhat ambivalent about removing the upper bounds for the 3 packages that are not upgradable (base, template-haskell, and ghc-prim). On one hand removing upper bounds doesn't introduce additional breakages and avoids having maintainers bump bounds on each GHC release* (~yearly), but on the other hand it creates worse error messages**. The solver could tell the user "Your package doesn't work with the version of base you have installed." instead of giving them a potentially confusing compilation error.

* I find it quite disconcerting that we bump the major version of base on every release. We shouldn't make breaking changes to the most core of core libraries on every release! I also note that GHC 7.4.1 seems to have bumped the major version on base even though no breaking change was made: https://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html


Though it's really a separate discussion, +1 on the idea of decreasing frequency of major version bumps in base and template-haskell.
 
** Although Cabal's dependency solver doesn't give the best messages today either. But at least it could be improved.

(3) This is already the case. We just don't encourage authors to do it (as maintaining version information in documentation rather than machine-checkable contracts tends to be hard to maintain.)



Yet in this same thread Erik said:

This sounds too vague to be an actual policy, so -1.

So it seems like the intention of the PVP itself is unclear at this point.

Michael

_______________________________________________
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

Michael Snoyman
In reply to this post by Henning Thielemann-4



On Wed, Apr 9, 2014 at 12:03 PM, Henning Thielemann <[hidden email]> wrote:
Am 09.04.2014 10:47, schrieb Michael Snoyman:


I would like to propose the following changes to the PVP. These are the
same changes that I recently published on the Yesod blog[1]. For more
information on the motivations behind these changes, please see that
blog post.

I see no need to complicate the PVP with distinctions about stable and unstable, published and unpublished packages. My preferred solution is to declare lower and upper version bounds in Build-Depends according to current PVP and ignore these bounds on demand via options that are passed to cabal-install.


There are two concrete needs I'm trying to address:

* From a library maintainer standpoint: decreased maintenance overhead. Being able to say `text < 2` or `case-insensitive < 2` means less time spent fiddling with cabal files.
* From a library user standpoint: it makes it less likely that you'll run into a case where cabal cannot create a build plan. If package foo places a restrictive upper bound on text of `text < 1.1`, and package bar starts using a new feature in text 1.1 and therefore has a bound `text >= 1.1`, the user won't be able to use foo and bar together until the author of foo bumps the version number.

The other needs I previously considered for this was testing newer versions of GHC, but the --allow-newer flag in cabal mostly[1] addresses this issue, so I don't think it's pertinent.

Note: this proposal doesn't actually impose a difference in behavior between published and non-published software. The PVP is already clearly not trying to ensure reproducible builds of packages on Hackage. I just want that clarity to extend to non-published code as well, since there seems to be some confusion.

Michael


_______________________________________________
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

Daniel Trstenjak-2

Hi Michael,

On Wed, Apr 09, 2014 at 01:29:18PM +0300, Michael Snoyman wrote:
> * From a library maintainer standpoint: decreased maintenance overhead. Being
> able to say `text < 2` or `case-insensitive < 2` means less time spent fiddling
> with cabal files.

I think that's mostly a tooling issue. It was my main motivation for
writing 'cabal-bounds' (https://github.com/dan-t/cabal-bounds).

> * From a library user standpoint: it makes it less likely that you'll run into
> a case where cabal cannot create a build plan. If package foo places a
> restrictive upper bound on text of `text < 1.1`, and package bar starts using a
> new feature in text 1.1 and therefore has a bound `text >= 1.1`, the user won't
> be able to use foo and bar together until the author of foo bumps the version
> number.

Yes, that's certainly a problem, but otherwise you also can't be sure
that 'text 1.1' didn't introduce a breaking change.

So with the new cabal flag '--allow-newer' the user could still try to build
with 'text 1.1' and the package could still indicate that it wasn't tried
with 'text 1.1', which at the end seems to be the best of both worlds.


Greetings,
Daniel
_______________________________________________
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

Michael Snoyman



On Wed, Apr 9, 2014 at 2:12 PM, Daniel Trstenjak <[hidden email]> wrote:

Hi Michael,

On Wed, Apr 09, 2014 at 01:29:18PM +0300, Michael Snoyman wrote:
> * From a library maintainer standpoint: decreased maintenance overhead. Being
> able to say `text < 2` or `case-insensitive < 2` means less time spent fiddling
> with cabal files.

I think that's mostly a tooling issue. It was my main motivation for
writing 'cabal-bounds' (https://github.com/dan-t/cabal-bounds).


While that can certainly *help*, the burden is still there. Even something as trivial as "go to dev machine, edit cabal file to say 1.2 instead of 1.1, cabal sdist, cabal update" takes time. If you want to do it properly (push to Github, wait for Travis to run test suites) it takes even more time.
 
> * From a library user standpoint: it makes it less likely that you'll run into
> a case where cabal cannot create a build plan. If package foo places a
> restrictive upper bound on text of `text < 1.1`, and package bar starts using a
> new feature in text 1.1 and therefore has a bound `text >= 1.1`, the user won't
> be able to use foo and bar together until the author of foo bumps the version
> number.

Yes, that's certainly a problem, but otherwise you also can't be sure
that 'text 1.1' didn't introduce a breaking change.


With this proposal, you can: we'd establish rules that you *can* depend on certain API subsets for a longer version range. So if I use that subset, I can be certain that 1.1 doesn't introduce a breaking change*.

* Unless of course the maintainer violates the agreement he's made with the users, but that's the same situation we're in right now with PVP upper bounds in general.
 
So with the new cabal flag '--allow-newer' the user could still try to build
with 'text 1.1' and the package could still indicate that it wasn't tried
with 'text 1.1', which at the end seems to be the best of both worlds.



There are two downsides to this:

* The goal is to simplify this process for end users. If the answer is "use --allow-newer," we're then (1) expecting end users to know this advice, and (2) we're removing most of the benefits of upper bounds. Like most things, either too much or too little is a bad thing. We need meaningful upper bounds to be enforced.
* --allow-newer conflates two concepts: upper bounds put in place due to a known breakage, and upper bounds put in place due to unknown changes. This isn't news: the fact that there's no such distinction in cabal for this has been brought up in the past. I gave an example of this problem on Reddit[1].

Michael


_______________________________________________
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 Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <[hidden email]> wrote:
Nonetheless, there is definitely confusion. The easiest way to see that is to look at the Reddit discussion of the blog post[1]. For example:

> Which implicitly includes supporting reproducible builds for "non-published software"

There are other examples in that discussion, as well as in the libraries@ discussion.

I think people were confused by your use of the word "reproducible", some take it to mean "if this package built before it will still build" (the PVP aims at this) and others to mean "build exactly the same bits as before". The PVP and people's interpretation of it doesn't seem to be confused, as seen by reading the rest of the comment you quoted. Put in other words, I don't think anyone believes the PVP is about freezing dependencies, as it's about the very opposite of that, namely allowing ranges of versions.
 
My proposed addition to the PVP itself would be the text:

While PVP compliance makes getting a successful build more likely, it does not try to encourage reproducible builds: builds which use exactly the same dependencies as previous builds. In particular: minor version bumps and changes in transitive dependencies can easily slip in. Reproducible builds are highly recommended for building production executables, and for that, dependency freezing is the only known solution (to be included in cabal-install after version X).

If we add it it should be as a footnote at the bottom. Bringing up this totally orthogonal issue is likely to confuse people more, not less.

Saying that the PVP makes builds more "likely" is understating the guarantee given quite a bit. With the exception of the issue with module and instance re-exports that has been discussed elsewhere and is mentioned on the PVP page, the PVP *guarantees* that things will build, if they built before.
 
** Although Cabal's dependency solver doesn't give the best messages today either. But at least it could be improved.

(3) This is already the case. We just don't encourage authors to do it (as maintaining version information in documentation rather than machine-checkable contracts tends to be hard to maintain.)



Yet in this same thread Erik said:

This sounds too vague to be an actual policy, so -1.

So it seems like the intention of the PVP itself is unclear at this point.

Quite intentionally so. We definitely not *want* to encourage people to add extra, non-checkable, ad-hoc policies on top of the PVP, we merely allow for them to do so. I noted that even though it's allowed not a single package I've seen does provide extra guarantees. 

-- Johan


_______________________________________________
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

Michael Snoyman



On Wed, Apr 9, 2014 at 2:40 PM, Johan Tibell <[hidden email]> wrote:
On Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <[hidden email]> wrote:
Nonetheless, there is definitely confusion. The easiest way to see that is to look at the Reddit discussion of the blog post[1]. For example:

> Which implicitly includes supporting reproducible builds for "non-published software"

There are other examples in that discussion, as well as in the libraries@ discussion.

I think people were confused by your use of the word "reproducible", some take it to mean "if this package built before it will still build" (the PVP aims at this) and others to mean "build exactly the same bits as before". The PVP and people's interpretation of it doesn't seem to be confused, as seen by reading the rest of the comment you quoted. Put in other words, I don't think anyone believes the PVP is about freezing dependencies, as it's about the very opposite of that, namely allowing ranges of versions.
 
My proposed addition to the PVP itself would be the text:

While PVP compliance makes getting a successful build more likely, it does not try to encourage reproducible builds: builds which use exactly the same dependencies as previous builds. In particular: minor version bumps and changes in transitive dependencies can easily slip in. Reproducible builds are highly recommended for building production executables, and for that, dependency freezing is the only known solution (to be included in cabal-install after version X).

If we add it it should be as a footnote at the bottom. Bringing up this totally orthogonal issue is likely to confuse people more, not less.

Saying that the PVP makes builds more "likely" is understating the guarantee given quite a bit. With the exception of the issue with module and instance re-exports that has been discussed elsewhere and is mentioned on the PVP page, the PVP *guarantees* that things will build, if they built before.
 

Maybe I'm more sensitive to this because I've had PVP advocates claim I broke their local builds by violating the PVP, when in fact it was specifically the exception that you mention that was the problem. That's why I both want to make it clear that the PVP doesn't guarantee reproducible builds, and why I don't put huge stock in the PVP guaranteeing that builds will always succeed. I've identified one set of holes in the PVP: typeclass instances and reexports leaking from transitive dependencies. Another hole is depending on packages which don't follow the PVP. Another hole is the fact that it's quite easy to make mistakes in trying to follow the PVP (I've been bitten by that multiple times in the past). And it's entirely possible that other holes exist today.

However, all of these problems are solved completely by version freezing. I think we need to be honest about the PVP: it does a good job of ensuring builds succeed most of the time, but it does not solve all problems. Should should be encouraging users to be using more reliable solutions. I'm worried that people are falsely relying on the PVP as a panacea for build problems.

So having specified all of that, maybe the wording I'm really hoping to add to the PVP is:

While the PVP addresses many causes of build failures, there are still cases it does not address(footnote to the list I just provided). These problems can be solved by version freezing, which is available in cabal-install since version X. It is highly recommended that users not rely exclusively on the PVP for the application builds, but instead use version freezing.
 
** Although Cabal's dependency solver doesn't give the best messages today either. But at least it could be improved.

(3) This is already the case. We just don't encourage authors to do it (as maintaining version information in documentation rather than machine-checkable contracts tends to be hard to maintain.)



Yet in this same thread Erik said:

This sounds too vague to be an actual policy, so -1.

So it seems like the intention of the PVP itself is unclear at this point.

Quite intentionally so. We definitely not *want* to encourage people to add extra, non-checkable, ad-hoc policies on top of the PVP, we merely allow for them to do so. I noted that even though it's allowed not a single package I've seen does provide extra guarantees. 



That's a chicken-and-egg scenario. No one knows they're allowed to do this, so no one does it, therefore we don't need to let anyone know they can do it.

And to be clear, I'm arguing that *yes*, we want to encourage people to define stable subsets of their API. Even better would be completely stable APIs, but I don't think that's a reasonable thing to expect in the immediate future.

Michael 

_______________________________________________
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

Erik Hesselink
On Wed, Apr 9, 2014 at 2:15 PM, Michael Snoyman <[hidden email]> wrote:
> However, all of these problems are solved completely by version freezing. I
> think we need to be honest about the PVP: it does a good job of ensuring
> builds succeed most of the time, but it does not solve all problems. Should
> should be encouraging users to be using more reliable solutions. I'm worried
> that people are falsely relying on the PVP as a panacea for build problems.

I think you're placing too much faith in version freezing. There
should still be a good story about upgrading the dependencies of a
'frozen' package. If this will result in lots of build failures
because of missing upper bounds (don't follow the PVP since we have
freezing) then this will be costly. So I think even in the presence of
freezing (which we don't have yet) I think the PVP is still important.
Also, I don't think we're going to freeze libraries on hackage, so
just installing a package to play with it will also still involve an
unfrozen build.

Erik
_______________________________________________
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

David Thomas
In reply to this post by Michael Snoyman

Might there be benefit to combining 3 and 4, making the stable subset explicit (perhaps supported by tests so as to be machine checkable)?

On Apr 9, 2014 1:47 AM, "Michael Snoyman" <[hidden email]> wrote:
I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post.

1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees.

2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.

3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.)

4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).)


_______________________________________________
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

Carter Schonwald
In reply to this post by Michael Snoyman
I'm  confused, Michael, have you documented your not PVP convention anywhere? 



On Wednesday, April 9, 2014, Michael Snoyman <[hidden email]> wrote:



On Wed, Apr 9, 2014 at 2:40 PM, Johan Tibell <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;johan.tibell@gmail.com&#39;);" target="_blank">johan.tibell@...> wrote:
On Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;michael@snoyman.com&#39;);" target="_blank">michael@...> wrote:
Nonetheless, there is definitely confusion. The easiest way to see that is to look at the Reddit discussion of the blog post[1]. For example:

> Which implicitly includes supporting reproducible builds for "non-published software"

There are other examples in that discussion, as well as in the libraries@ discussion.

I think people were confused by your use of the word "reproducible", some take it to mean "if this package built before it will still build" (the PVP aims at this) and others to mean "build exactly the same bits as before". The PVP and people's interpretation of it doesn't seem to be confused, as seen by reading the rest of the comment you quoted. Put in other words, I don't think anyone believes the PVP is about freezing dependencies, as it's about the very opposite of that, namely allowing ranges of versions.
 
My proposed addition to the PVP itself would be the text:

While PVP compliance makes getting a successful build more likely, it does not try to encourage reproducible builds: builds which use exactly the same dependencies as previous builds. In particular: minor version bumps and changes in transitive dependencies can easily slip in. Reproducible builds are highly recommended for building production executables, and for that, dependency freezing is the only known solution (to be included in cabal-install after version X).

If we add it it should be as a footnote at the bottom. Bringing up this totally orthogonal issue is likely to confuse people more, not less.

Saying that the PVP makes builds more "likely" is understating the guarantee given quite a bit. With the exception of the issue with module and instance re-exports that has been discussed elsewhere and is mentioned on the PVP page, the PVP *guarantees* that things will build, if they built before.
 

Maybe I'm more sensitive to this because I've had PVP advocates claim I broke their local builds by violating the PVP, when in fact it was specifically the exception that you mention that was the problem. That's why I both want to make it clear that the PVP doesn't guarantee reproducible builds, and why I don't put huge stock in the PVP guaranteeing that builds will always succeed. I've identified one set of holes in the PVP: typeclass instances and reexports leaking from transitive dependencies. Another hole is depending on packages which don't follow the PVP. Another hole is the fact that it's quite easy to make mistakes in trying to follow the PVP (I've been bitten by that multiple times in the past). And it's entirely possible that other holes exist today.

However, all of these problems are solved completely by version freezing. I think we need to be honest about the PVP: it does a good job of ensuring builds succeed most of the time, but it does not solve all problems. Should should be encouraging users to be using more reliable solutions. I'm worried that people are falsely relying on the PVP as a panacea for build problems.

So having specified all of that, maybe the wording I'm really hoping to add to the PVP is:

While the PVP addresses many causes of build failures, there are still cases it does not address(footnote to the list I just provided). These problems can be solved by version freezing, which is available in cabal-install since version X. It is highly recommended that users not rely exclusively on the PVP for the application builds, but instead use version freezing.
 
** Although Cabal's dependency solver doesn't give the best messages today either. But at least it could be improved.

(3) This is already the case. We just don't encourage authors to do it (as maintaining version information in documentation rather than machine-checkable contracts tends to be hard to maintain.)



Yet in this same thread Erik said:

This sounds too vague to be an actual policy, so -1.

So it seems like the intention of the PVP itself is unclear at this point.

Quite intentionally so. We definitely not *want* to encourage people to add extra, non-checkable, ad-hoc policies on top of the PVP, we merely allow for them to do so. I noted that even though it's allowed not a single package I've seen does provide extra guarantees. 



That's a chicken-and-egg scenario. No one knows they're allowed to do this, so no one does it, therefore we don't need to let anyone know they can do it.

And to be clear, I'm arguing that *yes*, we want to encourage people to define stable subsets of their API. Even better would be completely stable APIs, but I don't think that's a reasonable thing to expect in the immediate future.

Michael 

_______________________________________________
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

Felipe Lessa
In reply to this post by Michael Snoyman
Em 09-04-2014 05:47, Michael Snoyman escreveu:

> I would like to propose the following changes to the PVP. These are the
> same changes that I recently published on the Yesod blog[1]. For more
> information on the motivations behind these changes, please see that
> blog post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to
> ensure reproducible builds of non-published software, but rather to
> provide for more reliable builds of libraries on Hackage. Reproducible
> builds should be handled exclusively through version freezing, the only
> known technique to actually give the necessary guarantees.
>
> 2. Upper bounds should not be included on non-upgradeable packages, such
> as base and template-haskell (are there others?). Alternatively, we
> should establish some accepted upper bound on these packages, e.g. many
> people place base < 5 on their code.
>
> 3. We should be distinguishing between mostly-stable packages and
> unstable packages. For a package like text, if you simply import
> Data.Text (Text, pack, reverse), or some other sane subset, there's no
> need for upper bounds. (Note that this doesn't provide a hard-and-fast
> rule like the current PVP, but is rather a matter of discretion.
> Communication between library authors and users (via documentation or
> other means) would be vital to making this work well.)
>
> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries
> which use these packages are free to rely on the guarantees provided by
> package authors when placing upper bounds. (Note that this is very
> related to point (3).)
>
> Discussion period: 3 weeks.
>
> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
Needless to say since I'm mentioned on the blog post, +1.

--
Felipe.


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

signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Changes to the PVP

Michael Snoyman
In reply to this post by Carter Schonwald



On Wed, Apr 9, 2014 at 5:19 PM, Carter Schonwald <[hidden email]> wrote:
I'm  confused, Michael, have you documented your not PVP convention anywhere? 




I'm not sure what you're asking. The incident in question had nothing to do with PVP compliance or lack thereof. The proposal on the table is pretty close to what I use in practice right now. If this proposal is approved, I would likely start adding in upper bounds in accord with what the new standards would be. Right now, in cases of mostly-stable packages like text and bytestring, I've simply left off the upper bounds entirely.

Michael

_______________________________________________
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
One thing to keep in mind is that version freezing is only for application builders, that information probably needs to be included in information that educates about PVP vs. reproducible build.

Linking to the reddit discussion, a comment that had the most upvotes was completely confused on reproducible builds, here is the commenter's explanation of what a reproducible build is:

You're probably right; Simply stated, I considered "reproducible build" to mean that if there was a package on Hackage that I could cabal install foobar with a given GHC version at some point in time, I would be able to do that for each later point in time (e.g. 1 year later) using the very same GHC version (at least). Isn't that was the PVP was created to accomplish in the first place?



On Wed, Apr 9, 2014 at 7:48 AM, Michael Snoyman <[hidden email]> wrote:



On Wed, Apr 9, 2014 at 5:19 PM, Carter Schonwald <[hidden email]> wrote:
I'm  confused, Michael, have you documented your not PVP convention anywhere? 




I'm not sure what you're asking. The incident in question had nothing to do with PVP compliance or lack thereof. The proposal on the table is pretty close to what I use in practice right now. If this proposal is approved, I would likely start adding in upper bounds in accord with what the new standards would be. Right now, in cases of mostly-stable packages like text and bytestring, I've simply left off the upper bounds entirely.

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

Johan Tibell-2
On Wed, Apr 9, 2014 at 5:35 PM, Greg Weber <[hidden email]> wrote:
One thing to keep in mind is that version freezing is only for application builders, that information probably needs to be included in information that educates about PVP vs. reproducible build.

Linking to the reddit discussion, a comment that had the most upvotes was completely confused on reproducible builds, here is the commenter's explanation of what a reproducible build is:

You're probably right; Simply stated, I considered "reproducible build" to mean that if there was a package on Hackage that I could cabal install foobar with a given GHC version at some point in time, I would be able to do that for each later point in time (e.g. 1 year later) using the very same GHC version (at least). Isn't that was the PVP was created to accomplish in the first place?


He/she doesn't seem to be confused. He/she is just using a different meaning of the term "reproducible" than you and me i.e. meaning "if it built before it should still build". Such confusions are easily resolved by defining the terms one use in advance.

_______________________________________________
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 Wed, Apr 9, 2014 at 9:05 AM, Johan Tibell <[hidden email]> wrote:
On Wed, Apr 9, 2014 at 5:35 PM, Greg Weber <[hidden email]> wrote:
One thing to keep in mind is that version freezing is only for application builders, that information probably needs to be included in information that educates about PVP vs. reproducible build.

Linking to the reddit discussion, a comment that had the most upvotes was completely confused on reproducible builds, here is the commenter's explanation of what a reproducible build is:

You're probably right; Simply stated, I considered "reproducible build" to mean that if there was a package on Hackage that I could cabal install foobar with a given GHC version at some point in time, I would be able to do that for each later point in time (e.g. 1 year later) using the very same GHC version (at least). Isn't that was the PVP was created to accomplish in the first place?


He/she doesn't seem to be confused. He/she is just using a different meaning of the term "reproducible" than you and me i.e. meaning "if it built before it should still build". Such confusions are easily resolved by defining the terms one use in advance.

Sure, but the commenter did define their exact meaning of reproducible and stated they think that is what the PVP is for. This appears to be the definition of being confused about what the PVP is meant for. There isn't any situation in which the train of thought expressed here is useful in practice, particularly since we know that the PVP does not actually guarantee a package will install. The useful train of though is to distinguish between applications and libraries and state how dependency freezing is necessary for applications.

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