implement the Cabal ${pkgroot} spec extension

[duncan]

See the proposal for relative paths in installed package descriptions:

 http://www.haskell.org/pipermail/libraries/2009-May/011772.html

Basically it amounts to replacing ghc's current $topdir and $httptopdir with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).

The open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) hc-pkg system to discover the default set of package dbs and their paths.

[simonmar]

After discussion with Duncan, we decided to

• implement ghc-pkg pkgroot <package>, which returns the value of ${pkgroot} for the given package

• for ghc-pkg dump, we prefix each batch of packages with the pkgroot value (choosing some suitable syntax)

[duncan]

Replying to simonmar:

After discussion with Duncan, we decided to * implement ghc-pkg pkgroot <package>, which returns the value of ${pkgroot} for the given package

Oh, sorry, I wasn't clear. I don't think this is necessary. But if you want to do it anyway I'm not going to say no.

* for ghc-pkg dump, we prefix each batch of packages with the pkgroot value (choosing some suitable syntax)

Yes. Some suitable syntax we've not yet chosen :-)

[igloo]

See also #3072.

[duncan]

Replying to duncan:

* for ghc-pkg dump, we prefix each batch of packages with the pkgroot value (choosing some suitable syntax)

Yes. Some suitable syntax we've not yet chosen :-)

I've decided that the simplest thing to do is to just have it as an extra field:

pkgroot: /the/path/that/is/the/pkgroot

So this field may be in the output, but never in the input (if it is it's ignored like all other unknown fields).

There are two cases:

• --expand-vars: in this case ghc-pkg dump/describe will expand the ${pkgroot} and ${pkgrooturl} vars and will not generate the pkgroot field.
• --no-expand-vars: in this case ghc-pkg dump/describe will not expand the ${pkgroot} var, so it will appear literally in the output and the pkgroot field will be generated so that tools know what value to use for the ${pkgroot}.

The defaults are:

• ghc-pkg dump uses --no-expand-vars by default, but this can be reversed with --expand-vars
• ghc-pkg describe uses --expand-vars by default, but this can be reversed with --no-expand-vars

(Alternatively could be more explicit and say -(no-)expand-pkgroot.)

Sound sane?

None of this applies to hugs/nhc style file databases because there tools always know exactly what the pkgroot is, as it's just the dir containing the file they read. Because ghc-pkg has a looser connection between the package info and the locations they come from then we need this (or a similar) extra mechanism.

[simonmar]

Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg describe is slightly worrisome. That means ghc-pkg describe | ghc-pkg update is not the identity (I think we have a test that will break). What goes wrong if ghc-pkg describe uses --no-expand-vars by default?

[duncan]

Replying to simonmar:

Looks ok to me, though the difference between ghc-pkg dump and ghc-pkg describe is slightly worrisome. That means ghc-pkg describe | ghc-pkg update is not the identity (I think we have a test that will break).

It doesn't break yet because nothing uses ${pkgroot}. But yes, it'd have to be updated to use --no-expand-pkgroot.

What goes wrong if ghc-pkg describe uses --no-expand-vars by default?

It's simply that it'll surprise people and perhaps existing tools. I'm happy to give it a go and see what breaks :-)

[duncan]

Ok, so we'll make both dump and describe use the unexpanded form by default and provide --expand-pkgroot which should generate the previous format exactly.

ghc-pkg field will by default expand the ${pkgroot} but that can be altered via --no-expand-pkgroot.

[duncan]

Done!

commit 40b6bd47cf00f025426746bbd7abdd0eda2a3afd
Author: Duncan Coutts <duncan@well-typed.com>
Date:   Mon May 23 22:10:45 2011 +0100

    Implement ${pkgroot} spec, allows relocatable registered packages
    
    Historically ghc implemented relocatable packages by allowing
    "$topdir" in the package registration info and having ghc expand
    this with its notion of $topdir. The topdir refers to where ghc
    itself is installed (specifically the libdir).
    
    The ${pkgroot} spec takes this idea and makes it portable.
    (http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
    Instead of paths relative to where ghc is installed, they can be
    relative to the package database itself. Thus it is no longer a
    ghc-specific idea and can work for package collections other than
    the global package db.

commit f35a3d247e023b6c1b0abe677549b29398933b50
Author: Duncan Coutts <duncan@well-typed.com>
Date:   Wed May 25 13:06:14 2011 +0100

    Provide the pkgroot value in ghc-pkg dump & describe when necessary
    
    Tools handling installed packages need to be able to interpret the
    paths which are relative to the ${pkgroot} which means they need to
    know the value of ${pkgroot}. With ghc-pkg this is not always obvious
    since ghc-pkg does not currently have any way machine interface for
    reporting the location of its package dbs (global, user). The solution
    we have arrived at is simply to emit the pkgroot as an extra field
    when it is needed.
    
    There are two cases:
     * --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
       ${pkgroot} var, so it will appear literally in the output and the
       pkgroot field will be generated so that tools know what value to
       use for the ${pkgroot}.
     * --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
       and ${pkgrooturl} vars and will not generate the pkgroot field.
    
    The defaults are:
     * ghc-pkg dump/describe --no-expand-pkgroot
     * ghc-pkg field --expand-pkgroot

Also implemented in Cabal:

Wed May 25 12:47:42 BST 2011  Duncan Coutts <duncan@community.haskell.org>
  * Support ${pkgroot}-relative paths in installed package info from hc-pkg
  See http://hackage.haskell.org/trac/ghc/ticket/3268
  In new versions of ghc-pkg, ghc-pkg dump will emit an extra field like
  pkgroot: /the/path/that/is/the/pkgroot
  and other fields may contain ${pkgroot}, e.g.
  library-dirs: ${pkgroot}/blah/
  This allows relocatable packages, with package files installed
  relative to the package database itself.