Fixing "breaking packages"

[Johan Tibell]

On Fri, Mar 1, 2013 at 10:24 AM, Max Bolingbroke <batterseapower at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130301/95ab851f/attachment.htm>