Proposal: Changes to the PVP

[Michael Snoyman]

On Thu, Apr 10, 2014 at 12:30 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Wed, Apr 9, 2014 at 11:13 PM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> And this is where I think the PVP is doing a disservice with its current
>> wording. Users have this expectation, but it doesn't actually hold up in
>> reality. Reasons why it may fail include:
>>
>> * Typeclass instance leaking from transitive dependencies.
>> * Module reexports leaking from transitive dependencies.
>>
>
> We're aware of these two issues and the PVP page mentions one of them. It
> should also mention the other together with a workaround. These issues seem
> rare however. I've never run into them.
>
>
>> * Someone made a mistake in an upload to Hackage (yes, that really does
>> happy, and it's not that uncommon).
>>
>
> Nothing will help you in this case as a library author, as you cannot
> freeze your deps in your .cabal file, which would be the only option if
> you're worried about this.
>
>
>> * The package you depend on doesn't itself follow the PVP, or so on down
>> the stack.
>>
>
> Sure. You don't get benefits from the PVP if people don't follow the PVP.
>
> You second sentence suggests that there are other failure modes, I'd love
> to know about them so we can discuss them.
>
>
The point is that we don't know. The typeclass/reexport business went
undocumented until a few weeks ago, which took at least a few people by
surprise big time. Maybe those are the only issues that remain in the PVP.


> As I see it now there are two real failure modes (the first two you
> listed), one we can fix with tooling (make sure people follow the PVP), and
> one I don't think it's worth caring about (accidental uploads of broken
> stuff.)
>
>

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.

And if we're OK saying we'll retroactively change foo-1.0.0.1, we can just
as easily retroactively change packages to add in upper bounds.


>  So my point is: even though the *goal* of the PVP is to provide this
>> guarantee, it *doesn't* provide this guarantee. Since we have a clear
>> alternative that does provide this guarantee (version freezing), I think we
>> should make it clear that the PVP does not solve all problems, and version
>> freezing should be used.
>>
>
> It provides the guarantee with the exceptions of you two first points,
> which don't worry me much as I've never seen them happen outside the Yesod
> ecosystem (i.e. they seem rare.) Version freezing is orthogonal to the
> stuff the PVP talks about so I think we will just confuse users by talking
> about it in the PVP. Perhaps you could put together a little "how to build"
> stuff guide and raise awareness of the issue that way?
>
>
>
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.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/20132c2e/attachment.html>