On 1 March 2013 14:15, Ian Lynagh
On Fri, Mar 01, 2013 at 03:02:41PM +0100, Jan Stolarek wrote:
fixing things. I would like cabal to prevent such things from ever happening, the same way that Linux rpm/deb managers keep packages on the system in a consistent state.
There's one big difference here: rpm/dpkg are only used to install things by the system administrator. But in the case of Cabal, a user could install 'mypackage' (in their user package database) and the next day the sysadmin could install a different instance of 'mypackage' in the global database.
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... Max