Cabal and simultaneous installations of the same package

[Simon Peyton Jones]

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?

Correct, esp the bit that I have emboldened. For the former bullets, perhaps Cabal might ask you want you want to do.

That still leaves open questions.  What happens if you say “ghc –package P –package Q Foo.hs”?  Should GHC complain that you’ve chosen an inconsistent set?  Perhaps!

(NB if P and Q use containers only internally, and do not expose any types from containers, then arguably it’s ok; but I’d argue for jumping that bridge when we come to it.)

Simon

From: Michael Snoyman [mailto:michael at snoyman.com]
Sent: 23 March 2015 09:58
To: Simon Peyton Jones; cabal-devel at haskell.org
Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org
Subject: Re: Cabal and simultaneous installations of the same package


On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simonpj at microsoft.com<mailto: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/ghc-devs/attachments/20150323/dc756c7e/attachment.html>