Cabal and simultaneous installations of the same package

[Michael Snoyman]

On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> It's already a huge source of confusion for people using GHCi what they
> get messages about "ByteString is not ByteString."
>
>
>
> Reading your blog post [1] it seems that we are addressing different
> questions:
>
> ·         My proposal is only that the act of **installing** a package
> does not break existing installed package, and is not rejected because it
> risks doing so.
>
Thank you for the clarification, I had misread that. On that front: I
agree.

>  ·         You agree that the confusing behaviour you describe can’t
> happen with Cabal.  In any one build, Cabal can ensure that only one
> version of each package is used in the build, so such a message could never
> show up.
>
I've seen people discussing exactly such a change to Cabal's behavior, so I
mistakenly took your comments to be heading in that direction. While I
think there *might* be some future where we could expose that
functionality, it could be incredibly confusing. I'd feel much better
starting off with simply the act of installing.

>  ·         What you want is for the confusing behaviour to be true of
> GHCi too.  Well that’s simple enough: ensure that the set of *exposed*
> packages (ie the ones you say ‘import M’ for), is consistent in the same
> way.  The point is that I may need to install a bunch of packages to build
> a program.  If I’m using Cabal, none of those newly installed packages need
> be exposed; I simply need them there so I can compile my program (using
> Cabal).   But at the moment I can’t do that.
>
>
>
> That leaves open the following question. Suppose
>
> ·         I want to install *and expose* package P and Q
>
> ·         But alas, P depends on containers 2.9 and Q depends on
> containers 3.1
>
> Now I’m stuck. But there is a good reason for being stuck, and one that is
> explicable.
>
>
>

If I'm reading this correctly, the proposal then would be to have cabal
automatically hide packages (as oppose to unregister them) to arrive at a
world where all exposed packages are consistent. Extrapolating for the case
you mention above

* if I installed P and then Q, I'd end up with containers-3.1 and Q
exposed, and containers-2.9 and P hidden
* if I installed Q and then P, I'd end up with containers-2.9 and P
exposed, and containers-3.1 and Q hidden

But either way, all four package/versions would be available, and cabal
would be able to select an appropriate subset of packages when configuring.
Does that sound about right?

Michael

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150323/bfadccc8/attachment.html>