Cabal and simultaneous installations of the same package
Simon Peyton Jones
simonpj at microsoft.com
Mon Mar 23 20:13:53 UTC 2015
But I'm hazy about why sandboxes are needed at all. As I understand it, they were invented to solve the very problem that is now solved (if only Cabal could take advantage of it).
From: Gershom B <gershomb at gmail.com>
Sent: 23 March 2015 17:31
To: Simon Peyton Jones
Cc: cabal-devel at haskell.org; 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 4:45 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> | 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.
My understanding is that the problem Yitz is discussing is much more
straightforward and easy to fix.
The issue is that if I have an "empty" global package db and enter a
sandbox and cabal-install something, then I will get one package
install plan. But if I have a "well populated" package db, then
attempt to cabal-install something in the sandbox, the plan will
attempt to use the packages from that global db, and so will often be
a different, and perhaps worse plan (especially if it runs into quirks
in the solver).
This is discussed on the associated reddit thread here:
As I proposed on the main email thread, I think it would make sense to
make the easy, default option the one which, in sandboxes, effectively
ignores the global db for solving. This leads to more duplication and
longer build times, but it is safer. However, we should have an easy
setting/flag (to be set when initializing a sandbox or any time
thereafter) which can switch the preference over to preferring to use
already installed versions in the global db. That way, new users can,
naively, get a _lot_ of isolation with sandboxes, and those who know
what they are doing can opt out in order to reduce duplication of
installs and cut down on build times.
Addition of a `prefer-global-db` flag and a good default setting for
it (i.e., false) seems to me like it would resolve the _central_ issue
people have with the platform, and situate us well to unilaterally
recommend it as the default install option.
More information about the cabal-devel