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
