On Fri, Mar 1, 2013 at 10:24 AM, Max Bolingbroke <batterseapower@hotmail.com
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.