I've now added GHC_PACKAGE_PATH, as requested. Also, I've cleaned up the ghc-pkg options. The basic idea is this: we separate the concept of the "stack of package databases" from the database that is being modified by ghc-pkg.
The --user and --global flags have no effect on the stack of package databases; the stack is built up by taking into account GHC_PACKAGE_PATH, the user & global databases, and any --package-conf options. The stack is printed out by 'ghc-pkg list'. The database to be modified is given by the rightmost (--global, --user, --package-conf) option, defaulting to the global database. So --package-conf has a dual role: it both adds to the stack, and also specifies the database to modify. This is the bit that isn't entirely satisfactory; really we should have two options, but that seemed overly confusing. To let --package-conf function in the role of just "selecting which database to modify", it now doesn't add to the stack if the database it names is already on the stack somewhere. I think this tidies things up a bit. Comments? Cheers, Simon On 08 September 2005 22:52, Frederik Eaton wrote: > It appears that the "--global" option to ghc-pkg causes the program to > forget all of the preceding package configuration options. > > Here we get results for all three options: > > $ /usr/bin/ghc-pkg list --global --user --package-conf=testp.conf > /usr/lib/ghc-6.4/package.conf: > ... > (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) > /home/frederik/.ghc/i386-linux-6.4/package.conf: > testp.conf: > WashNG-2.4.6-ng > > Now --global screens --user: > > $ /usr/bin/ghc-pkg list --user --global --package-conf=testp.conf > /usr/lib/ghc-6.4/package.conf: > ... > (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) > testp.conf: > WashNG-2.4.6-ng > > Now --global screens everything: > > $ /usr/bin/ghc-pkg list --user --package-conf=testp.conf --global > /usr/lib/ghc-6.4/package.conf: > ... > (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) > > The following illustrates that --user does not have the same drawback: > > $ /usr/bin/ghc-pkg list --package-conf=testp.conf --user > /usr/lib/ghc-6.4/package.conf: > ... > (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) > /home/frederik/.ghc/i386-linux-6.4/package.conf: > testp.conf: > WashNG-2.4.6-ng > > This is very confusing, and not very useful! > > I would suggest the following modification: > > 1. --global should behave just like --user and --package-conf, i.e. it > should augment rather than reset the current list of package > databases. > > And either: > > 2a. There should be a --no-global option which causes the global > package.conf not to be included by default. Thus --global only has an > effect when --no-global has been specified. This is messy, but will > preserve behavior which is relied upon by Cabal, etc. > > -or- > > 2b. The global package database should only be included by default > when no --package-conf or --user option is present. Otherwise, the > global package database should not be automatically included; --global > must be specified to include it. This will probably break some things > which assume that e.g. "ghc-pkg list --user" will include global > packages as well. > > > Both of these solutions are kind of messy. It's too bad that the > present system has come so far with these issues unaddressed, but now > I imagine that backwards compatibility is a concern. > > Also, I would suggest that: > > 3. ghc, ghci, ghc-pkg, etc. should respond to an environment variable > GHC_PKG_PATH which contains a colon-separated list of package > databases, to be included as if they had been specified on the > command-line with --package-conf or -package-conf. > > This would allow one to create environments consisting of different > sets of packages, without creating new users or buying new computers > to host them. Such is a feature of every other major compiler or > interpreter in existence. > > Frederik _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs