Ok, I've read through this discussion. Could somebody explain to me why this whole "virtualization" thing can't be solved by simply adding the flag --package-db=<file> to Cabal? It would be another option in the --user/--global family. The idea isn't new - I'm sure we've discussed this before. It seems to suffer from none of the problems of the other suggestions, but perhaps I'm missing something. For Hugs, the <file> would actually specify a directory. Additionally, --package-db=<file> is a step on the way to other things that we want to do (--in-place). It seems to me that the requirement is basically this: - To be able to install packages in a group, such that all packages in the group are registered in a single, separate, package database. the fact that in the proposed use cases the packages are also installed under a pseudo-root is a red herring as far as Cabal is concerned. We don't care where you install your packages or what files they contain. So the question becomes how to specify which "package group" a package should be registered in. I propose the simplest thing: tell Cabal the location of a package database. The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO. I'm happy to add support for GHC_PACKAGE_PATH, as requested in this discussion. Cheers, Simon
"Simon Marlow"
Ok, I've read through this discussion. Could somebody explain to me why this whole "virtualization" thing can't be solved by simply adding the flag
--package-db=<file>
to Cabal? It would be another option in the --user/--global family. The idea isn't new - I'm sure we've discussed this before. It seems to suffer from none of the problems of the other suggestions, but perhaps I'm missing something. For Hugs, the <file> would actually specify a directory. Additionally, --package-db=<file> is a step on the way to other things that we want to do (--in-place).
The problem I have with --package-db= as a directory for Hugs (and nhc, and jhc) is that it conflicts with the meaning of the --prefix flag. That is, if you specify a package database, it changes the location of the installation, which is not what you might expect. Also, we'd have to make sure people don't try to use --prefix and --package-db together in the case of Hugs (unless they're equal).
It seems to me that the requirement is basically this:
- To be able to install packages in a group, such that all packages in the group are registered in a single, separate, package database.
the fact that in the proposed use cases the packages are also installed under a pseudo-root is a red herring as far as Cabal is concerned. We don't care where you install your packages or what files they contain.
Right, but it matters for Hugs because of how Hugs finds packages.
So the question becomes how to specify which "package group" a package should be registered in. I propose the simplest thing: tell Cabal the location of a package database.
Another option, since this will only really work for GHC, is to add --ghc-options and --ghc-pkg-options and people can specifcy the database they want, and it'll be clear that it's not a portable option.
The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO.
So for the sake of those who haven't read the wiki page, here's my --root= proposal. This basically directly implements "virtualization" in Cabal: * For GHC o --prefix now becomes $(ROOT)/$(PREFIX) o the ghc-pkg file is stored in $(ROOT)/.whatever o Cabal adds package-conf related flags to ghc and ghc-pkg to look at $(ROOT)/.whatever. * For Hugs o -P$(ROOT)/usr/lib/hugs will be added o Hugs still has issues if --prefix isn't something Hugs knows about (as now). See web page below for comments on how to solve that problem. http://www.haskell.org/hawiki/Cabal_2fVirtualizationRequirements I like this because it makes sense for GHC, Hugs, nhc, and jhc. I agree that finding the package database for GHC is a bit of magic at that point, but really what --root= is saying is just the same as --package-db=, except that it's admitting that you can't do this without changing the installation location for Hugs, etc. So the location of packages.conf is derived from --root instead of being directly specified by --package-db. I don't think that's a lot of magic. peace, isaac
On 16.09 10:02, Isaac Jones wrote:
The problem I have with --package-db= as a directory for Hugs (and nhc, and jhc) is that it conflicts with the meaning of the --prefix flag. That is, if you specify a package database, it changes the location of the installation, which is not what you might expect. Also, we'd have to make sure people don't try to use --prefix and --package-db together in the case of Hugs (unless they're equal).
This could be solved by --ghc-package-db, which would be also admitting that it is only a solution for GHC. For virtualization the solution with JHC will probably be: 1) The virtual root is e.g. /foo/bar 2) export JHCPATH=/foo/bar 3) runhaskell Setup.lhs --prefix=/foo/bar --package-db would not make much sense.
The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO.
So for the sake of those who haven't read the wiki page, here's my --root= proposal. This basically directly implements "virtualization" in Cabal:
* For GHC o --prefix now becomes $(ROOT)/$(PREFIX) o the ghc-pkg file is stored in $(ROOT)/.whatever o Cabal adds package-conf related flags to ghc and ghc-pkg to look at $(ROOT)/.whatever. * For Hugs o -P$(ROOT)/usr/lib/hugs will be added o Hugs still has issues if --prefix isn't something Hugs knows about (as now). See web page below for comments on how to solve that problem.
This is evil. If given --prefix then the user will want things to live there. This forces a fixed layout under the throats of users. This would be mean that my current ${HOME}/local would become ${HOME}/local/usr/lib/... which is unlike other applications.
http://www.haskell.org/hawiki/Cabal_2fVirtualizationRequirements
I'll try add comments there. - Einar Karttunen
On Fri, Sep 16, 2005 at 01:16:26PM +0100, Simon Marlow wrote:
Ok, I've read through this discussion. Could somebody explain to me why this whole "virtualization" thing can't be solved by simply adding the flag
--package-db=<file>
Nope, can't explain it! Seems like a good solution to me too. Although I think it would be nice if Cabal were able to automatically pick a "standard" package database which is a function of the 'prefix' (hence the --default-package-db option I mention on the wiki); that is not crucial, if we think that it would add too much complexity. The --user and --global options would let users specify the standard databases in the most common cases.
... It seems to me that the requirement is basically this:
- To be able to install packages in a group, such that all packages in the group are registered in a single, separate, package database.
the fact that in the proposed use cases the packages are also installed under a pseudo-root is a red herring as far as Cabal is concerned. We don't care where you install your packages or what files they contain.
That seems correct. I might say that, although it is not in itself a requirement, it certainly satisfies all the other requirements, and there is no reason not to be simple and general.
So the question becomes how to specify which "package group" a package should be registered in. I propose the simplest thing: tell Cabal the location of a package database. The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO.
I'm happy to add support for GHC_PACKAGE_PATH, as requested in this discussion.
Excellent. (Jacques Frechet, the author of Toast, has spent some time modifying Toast so that versions of GHC it installs have their binaries wrapped to support this environment variable, but I thought his solution was always a bit hacky. It would be good to have actual support in GHC.) Frederik -- http://ofb.net/~frederik/
participants (4)
-
Einar Karttunen -
Frederik Eaton -
Isaac Jones -
Simon Marlow