On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones <simo...@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 >
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel