Re: cabal design

On Mon, Aug 22, 2005 at 08:27:57PM -0700, Isaac Jones wrote:

Frederik Eaton 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/