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. · 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. · 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. Simon From: Michael Snoyman [mailto:mich...@snoyman.com] Sent: 23 March 2015 08:53 To: Simon Peyton Jones; cabal-devel@haskell.org Cc: haskell-platf...@projects.haskell.org; haskell-infrastruct...@community.galois.com; Haskell Libraries; ghc-d...@haskell.org Subject: Re: Cabal and simultaneous installations of the same package I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote: Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon _______________________________________________ Libraries mailing list librar...@haskell.org<mailto:librar...@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
