On Wed, Apr 9, 2014 at 2:40 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
On Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <michael@snoyman.com> 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