Proposal: Changes to the PVP

Wed Apr 9 21:13:44 UTC 2014

On Wed, Apr 9, 2014 at 10:57 PM, MightyByte <mightybyte at gmail.com> wrote:

> Here's my view.
>
> 1a. I don't know how to answer this question because I have no idea
> what "good enough job" means.
> 1b. Unequivocally yes, we should do our best to support this
> expectation to the best of our ability.  However we can't state it as
> strongly as "no matter what happens".  I think we can say "as long as
> all of his dependencies are well-behaved, the package should be pretty
> likely to build..."
>

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.
* Someone made a mistake in an upload to Hackage (yes, that really does
happy, and it's not that uncommon).
* The package you depend on doesn't itself follow the PVP, or so on down
the stack.

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.

> 1c. If "always run in the same way" means that it will always be built
> with the same set of transitive dependencies, then no.
> 2a is a bit stickier.  I want to say yes, but right now I'll leave
> myself open to convincing.  My biggest concern in this whole debate is
> that users of the foo package should specify some upper bound, because
> as Greg has said, if you don't, the probability that the package
> builds goes to ZERO (not epsilon) as t goes to infinity.  Personally I
> like the safe and conservative upper bound of <1.3 because I think
> practically it's difficult to make more granular contracts work in
> practice and it follows the PVP's clear meaning.  If you're committing
> to support the same API up to 2.0, why can't you just commit to
> supporting that API up to 1.3?  The author of foo still has the
> flexibility to jump to 2.0 to signal something to the users, and when
> that happens, the users can change their bounds appropriately.
>
>
This sounds more like a personal opinion response rather than
interpretation of the current PVP. I find it troubling that we're holding
up the PVP as the standard that all packages should adhere to, and yet it's
hard to get an answer on something like this.

The point of giving a guarantee to 2.0 is that it involves less package
churn, which is a maintenance burden for developers, and removes extra
delays waiting for maintainers to bump version bounds, which can lead to
Hackage bifurcation.

But again, my real question is: what does the PVP say right now? We can't
even have a real discussion of my initial proposal if no one can agree on
what the PVP says about that situation right now!

Michael

> On Wed, Apr 9, 2014 at 3:22 PM, Michael Snoyman <michael at snoyman.com>
> wrote:
> > I have to say, the responses on this thread are truly confusing. Let's
> > ignore point (3) of my proposal (since it can essentially be subsumed
> under
> > (4)). Point (2) is clearly a change in the PVP, and boils down to "users
> get
> > cabal error messages" or "users get GHC error messages." I understand
> > (though strongly disagree with) those opposed to the change I'm proposing
> > there. So let's ignore it.
> >
> > For (1) and (4), the responses vary from support, to opposition, to
> "that's
> > what the PVP already says." So there's clearly a problem here, and I
> don't
> > think the problem is in my proposal: people have very different ideas of
> > what the PVP actually expects of us.
> >
> > So forget my proposal for the moment, I want to engage in a thought
> > experiment. What does the current PVP say about the following scenarios:
> >
> > 1. A user is writing an application based on a number of Hackage
> libraries.
> > He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1,
> > aeson >= 0.7 && < 0.8`.
> >     a. Has he done a good enough job of writing his application?
> >     b. Should he have an expectation that, no matter what happens, his
> > software will always build when running `cabal clean && cabal install`
> > (assuming same GHC version and OS)?
> >     c. Should he have an expectation that the code will always run in the
> > same way it did when first built?
> > 2. I author a package called foo and release version 1.2 with the
> statement:
> > "I guarantee that the Foo module will exist and continue to export the
> foo1
> > and foo2 functions, with the same type signature, until version 2.0."
> >     a. If a user of the foo package only uses the foo1 and foo2
> functions,
> > is he "in violation" of the PVP by using a bound on the foo package of
> `foo
> >>= 1.2 && < 2`?
> >
> >
> >
> > On Wed, Apr 9, 2014 at 11:47 AM, Michael Snoyman <michael at snoyman.com>
> > 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).)
> >>
> >> Discussion period: 3 weeks.
> >>
> >> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/dfbb38dd/attachment-0001.html>