On Wed, Apr 9, 2014 at 6:28 PM, Greg Weber <greg@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