Proposal: Changes to the PVP
Johan Tibell
johan.tibell at gmail.com
Wed Apr 9 18:01:55 UTC 2014
On Wed, Apr 9, 2014 at 6:28 PM, Greg Weber <greg at gregweber.info> wrote:
>
> Sure, but the commenter did define their exact meaning of reproducible and
> stated they think that is what the PVP is for. This appears to be the
> definition of being confused about what the PVP is meant for.
>
Here's what the commenter said:
You're probably right; Simply stated, I considered "reproducible build" to
> mean that if there was a package on Hackage that I could cabal install
> foobar with a given GHC version at some point in time, I would be able to
> do that for each later point in time (e.g. 1 year later) using the very
> same GHC version (at least). Isn't that was the PVP was created to
> accomplish in the first place?
This definition of reproducible builds is exactly what the PVP guarantees.
If you define your dependency bounds as implied by the PVP and the packages
you depend on follow the PVP your package will continue to build in the
future, if it built today*. That doesn't mean that it will always use the
exact same versions that were used today, but the commenter didn't suggest
that.
> There isn't any situation in which the train of thought expressed here is
> useful in practice, particularly since we know that the PVP does not
> actually guarantee a package will install.
>
I wasn't aware. When doesn't PVP guarantee that a package will install?
> The useful train of though is to distinguish between applications and
> libraries and state how dependency freezing is necessary for applications.
>
This hasn't nothing to do with what's being discussed.
* The caveat about instance/module re-export leaks that was mentioned
before still applies.
-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/5761456b/attachment.html>
More information about the Libraries
mailing list