cabal design

[Frederik Eaton]

On Mon, Aug 22, 2005 at 08:27:57PM -0700, Isaac Jones wrote:
> Frederik Eaton <frederik at a5.repetae.net> writes:
> 
> (snip)
> > So, the whole point of wigwam, and a feature of toast, is to allow
> > things to be installed in multiple different "roots" ("playpens" in
> > wigwam). The idea is that you may want to install, say, a web server
> > and a bunch of its dependencies in one root, so that it can be tested
> > and deployed in a completely encapsulated and reliable manner. You may
> > want to test it independently of different versions of the same things
> > in other roots, or you may want to deploy it side-by-side with an
> > older version on a front-end server so that it is possible to
> > seamlessly switch between old and new versions. If all roots share a
> > package database, then you end up having to give the things which are
> > installed in those roots separate version numbers in order to keep the
> > package registrations from overwriting each other.
> 
> I see.  Gentoo has this sort of thing as well. 

Really? That makes me inclined to switch.

> I had thought that in such cases, GHC itself would be installed in
> the same "root" as this version of Cabal and the packages that you
> want to test, in which case, ghc-pkg would use a different package
> database. Is that not the case?

I have actually been using this feature, however, I don't think it
should be required. Partly because of the space overhead

$ du -sh .toast-i386/pkg/ghc/v6.4-i386-unknown-linux/
239M    .toast-i386/pkg/ghc/v6.4-i386-unknown-linux/

, partly because of the fact that "creating a new root" shouldn't
require "installing a new version of every compiler system"...
Typically not everything goes into the root, just the stuff which is,
say, necessary to servers at runtime.

A third reason is that one should be able to use packages installed in
user and global package databases, and package databases from multiple
roots, simultaneously. My choice of the term "root" here was perhaps a
bit unwise. I don't mean to refer to a thing that you are limited to
using 1 of, it's just a place where a bunch of packages may be
installed. So for instance Cabal currently recognizes 2 "roots", the
"user" and the "global". In addition on my system I have the toast
root. You can have a compiler in each root and rely on this hack to
get separation of package databases, but you would still need a way to
specify which of these databases you want to pull packages from when
you compile an additional package, which would require support from
Cabal. Well, I guess this would be possible if ghc recognized
environment variables and Cabal didn't clear the environment.

Configuring an environment to use several roots is simple when
environment variables are recognized by tools. On my system, I have
for instance

$ print -l $CPATH $MANPATH $INFOPATH $LIBRARY_PATH $LD_LIBRARY_PATH
/home/frederik/.toast-i386/armed/include:/home/frederik/include
/home/frederik/.toast-i386/armed/man:/home/frederik/share/man:/usr/local/share/man:/usr/share/man
/home/frederik/.toast-i386/armed/info:/home/frederik/info
/home/frederik/.toast-i386/armed/lib:/home/frederik/arch/i386/lib:/home/frederik/arch/i386/lib/mysql
/home/frederik/.toast-i386/armed/lib:/home/frederik/arch/i386/lib:/home/frederik/arch/i386/lib/mysql

It is rather difficult to do any other way. This is why I asked (on
March 9) for environment variable support in ghc, and was rather
disappointed to find that lack of support was actually intentional:

simonmar> There's the GHCRTS environment variable that you can use for setting
simonmar> heap sizes and so on, and the ~/.ghci file, but nothing for setting ghc
simonmar> command-line arguments.  We're a bit wary of adding more things that we
simonmar> have to ask for in a bug report...

Remember that one of the most common uses for this sort of
virtualization support is QA!

Frederik

-- 
http://ofb.net/~frederik/