Proposal: Changes to the PVP

[Carter Schonwald]

i'm currently -1 on this myself too for now.


On Wed, Apr 9, 2014 at 2:01 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> 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/3fdbd826/attachment.html>