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