Proposal: Changes to the PVP

[Carter Schonwald]

I'm  confused, Michael, have you documented your not PVP convention
anywhere?



On Wednesday, April 9, 2014, Michael Snoyman <michael at snoyman.com> wrote:

>
>
>
> On Wed, Apr 9, 2014 at 2:40 PM, Johan Tibell <johan.tibell at gmail.com<javascript:_e(%7B%7D,'cvml','johan.tibell at gmail.com');>
> > wrote:
>
>> On Wed, Apr 9, 2014 at 12:23 PM, Michael Snoyman <michael at snoyman.com<javascript:_e(%7B%7D,'cvml','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/2995027e/attachment.html>