qualified imports, PVP and so on

[Michael Snoyman]

On Wed, Feb 26, 2014 at 12:52 AM, Herbert Valerio Riedel <hvr at gnu.org>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.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/b5514e78/attachment-0001.html>