qualified imports, PVP and so on

[Herbert Valerio Riedel]

On 2014-02-26 at 06:45:30 +0100, Michael Snoyman wrote:
> On Wed, Feb 26, 2014 at 12:52 AM, Herbert Valerio Riedel wrote:
>> On 2014-02-25 at 21:38:38 +0100, Michael Snoyman wrote:
>>
>> [...]
>>
>> > * The PVP itself does *not* guarantee reliable builds in all cases. If a
>> > transitive dependency introduces new exports, or provides new typeclass
>> > instances, a fully PVP-compliant stack can be broken. (If anyone doubts
>> > this claim, let me know, I can spell out the details. This has come up in
>> > practice.)
>>
>> ...are you simply referring to the fact that in order to guarantee
>> PVP-semantics of a package version, one has to take care to restrict the
>> version bounds of that package's build-deps in such a way, that any API
>> entities leaking from its (direct) build-deps (e.g.  typeclass instances
>> or other re-exported entities) are not a function of the "internal"
>> degree of freedoms the build-dep version-ranges provide? Or is there
>> more to it?
>
> That's essentially it. I'll give one of the examples I ran into. (Names
> omitted on purpose, if the involved party wants to identify himself, please
> do so, I just didn't feel comfortable doing so without your permission.)
> Version 0.2 of monad-logger included MonadLogger instances for IO and other
> base monads. For various reasons, these were removed, and the version
> bumped to 0.3. This is in full compliance with the PVP.
>
> persistent depends on monad-logger. It can work with either version 0.2 or
> 0.3 of monad-logger, and the cabal file allows this via `monad-logger >=
> 0.2 && < 0.4` (or something like that). Again, full PVP compliance.
>
> A user wrote code against persistent when monad-logger version 0.2 was
> available. He used a function that looked like:
>
> runDatabase :: MonadLogger m => Persistent a -> m a
>
> (highly simplified). In his application, he used this in the IO monad. He
> depended on persistent with proper lower and upper bounds. Once again, full
> PVP compliance.
>
> Once I released version 0.3 of monad-logger, his next build automatically
> upgraded him to monad-logger 0.3, and suddenly his code broke, because
> there's no MonadLogger instance for IO.
>
> Now *if* the program had been using a system like "cabal freeze" or the
> like, this could have never happened: cabal wouldn't be trying to
> automatically upgrade to monad-logger 0.3.
>
> Will this kind of bug happen all the time? No, I doubt it. But if the point
> of the PVP is to guarantee that builds will work (ignoring runtime
> concerns), and the PVP clearly fails at that job as well, we really need to
> reassess putting ourselves through this pain and suffering.

>From my point of view, I'd argue that 

 a) 'persistent' failed to live up to the "spirit" of the PVP contract,
    i.e. to expose a "contact-surface" which satisfies certain
    invariants within specific package-version ranges.

 b) However, the PVP can be blamed as well, as in its current form it
    doesn't explicitly address the issue of API-leakage from transitive
    build-dependencies. [1]

The question for me now is whether the PVP is fixable in this respect,
and at what cost.

Moreover, it seems to me, it always comes down to type-class instances
causing most problems with the PVP (either by requiring version-bump
cascades throughout the PVP-adhering domain of Hackage, or by their hard
hard to constraint leakage through package module/boundaries); maybe we
need address this issue at the language-level and provide some facility
for limiting the propagation of type-class instances first.



 [1]: An alternative to what I'm suggesting in 'a)' (i.e. that it'd be
      `persistent`'s obligation), could be that the package you
      mentioned (which broke due to monad-logger having a non-monotonic
      API change), might become required to include packages supplying
      the instances they depends upon in their build-depends, thus
      turning an transitive dep into a direct dependency.

Cheers,
  hvr