Proposal: Changes to the PVP

[Michael Snoyman]

On Wed, Apr 9, 2014 at 2:40 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <michael at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/7ae440e0/attachment-0001.html>