It sounds like a good solution, and I'm very grateful that you have implemented it.
Frederik On Fri, Nov 04, 2005 at 04:14:05PM -0000, Simon Marlow wrote: > 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
