On 15 July 2005 08:16, Isaac Jones wrote:

We basically have three dimensions of a single package to consider: - hidden vs. exposed - user vs. global vs. -package-conf - versions

I propose that -package-conf packages have priority over user packages which have priority over global packages (are all three considered at the same time?)

What do we do if multiple "dimensions" of the same package are exposed? Right now, ghc just quits, right? I propose:

Pick the Exposed -package-conf package with greatest version number

if none, the exposed user package with greatest version number

if none, the exposed system package with the greatest version number.

Hmm, I had in mind something simpler, but slightly different: (a) Pick the exposed package with the greatest version number, from all the packages that we know about (-package-conf, user, global). (b) If multiple packages have the same name *and* version, we take the first one in the order -package-conf, user, global. This differs from your version when you want to install an *older* version in your user database. eg. /usr/lib/ghc/package.conf: foo-2.0 /home/simonmar/.ghc/package.conf: foo-1.0 I'll always get foo-2.0 by default, but you would get foo-1.0. In both cases you can force foo-1.0 with '-package foo-1.0'. In both cases you can force the opposite behaviour by copying foo-2.0 into the user package database and exposing/hiding it respectively. IMO, my version is a bit easier to understand. eg. in my version, both of these commands result in the same outcome when foo-2.0 is installed globally: $ ghc-pkg register foo-1.0 --user $ ghc-pkg register foo-1.0 --global but in your version they differ. [ stares out the window for a bit... ] You might well ask what the point of exposed vs. hidden is, in the light of these changes. Can't we just pretend all packages are exposed all the time? Here are some reasons why not: - -hide-all-packages is useful for forcing complete explicitness about dependencies. Code that wants to be portable should always be using this. - hiding is useful for overriding the defaults, for example if you want to install a newer version of a package but not make it the default, or if you need to avoid conflicts in the set of packages that GHC would otherwise enable by default. But it's true that in the light of these changes, setting the exposed flag to False in the package database will be a rare occurrence. Cheers, Simon