On Fri, Mar 1, 2013 at 10:24 AM, Max Bolingbroke <[email protected] > wrote:
> I thought that "cabal install" should be viewed as installing an > instance of the requested package by recompiling the whole transitive > closure of dependencies from scratch, in a sort of NixOS-like way. > Given this view, Cabal's reuse of already compiled and installed > packages is purely an optimization that can prevent it from > recompiling some things if it is absolutely certain that doing so is > unnecessary. The problem then is just that Cabal is currently brokenly > unable to handle multiple instances of an installed package with the > same name and version. In this view, the existence of local and global > databases is straightforward: packages should always be installed in > the most-accessible DB to which you have write permissions (for > maximum sharing) and should be sourced from whichever is convenient > when they are required. > > There are two complicating factors: > 1. Some packages cannot be recompiled by the user (such as base) > which breaks the mental model a bit. This s probably not too > important. > 2. In this view, does "cabal install mylibrary-1.1" actually do > anything useful? The very next program you write that tries to link > against mylibrary-1.1 may end up requiring a differently-compiled > version because of its own dependency constraints. Of course, "cabal > install myexe-1.1" is perfectly useful and well defined, and it should > be the case that if "cabal install my-dep-1 my-dep-2 ... my-dep-N" > immediately preceds "cabal build" of a package with dependencies > (my-dep-i) then compilation of that package should proceed without > requiring any dependencies to be recompiled. > > It seems to me that the ideal mental model for "cabal install > mylibrary-1.1" is that it appends to a global mapping from package > name to version which are essentially the packages that are available > when you do "ghc -package mylibrary" and when using ghci. Cabals > promise should be that it adds the requested package to the global > mapping and then recompiles *everything* on your system as necessary > in order to make it possible for every package in that global mapping > to be imported simultaneously into a GHCi session. > > This seems like a vaguely sensible model of how things *should* work > to me, unless I've overlooked some horrible complication. I know that > Duncan is pretty keen on Nix so this the above plan may even be his > final intention. But of course, saying all that is one thing, but > finding the time to implement it quite another... > This is the model I've been arguing for in e.g. http://blog.johantibell.com/2012/03/cabal-of-my-dreams.html It's the only model I believe scales to e.g. executables that depend on thousands of packages (which happens for us at work). At that number of dependencies building needs to be hermetic. cabal install <lib> should just be a connivence thing you can use if you e.g. want to poke around a library using ghci or need to have the library available when you're offline.
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
