Cabal and simultaneous installations of the same package
michael at snoyman.com
Mon Mar 23 09:58:29 UTC 2015
On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simonpj at microsoft.com>
> 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  it seems that we are addressing different
> · 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
> · 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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs