Multi-instance packages status report

[Edward Z. Yang]

Hello all,

As you may have noticed, I've been knocking around GHC and Cabal the
past few weeks.  One of the tasks that has been on my list is
essentially reimplementing Philipp Schuster's 2012 GSoC, with a few
small but important architectural differences.  Here is a status report
of what is going on.

In my copy of GHC and Cabal [1,2], you can now install multiple copies of a
package with differing dependencies to the package database, i.e. q-1.0
compiled against p-1.0, and against p-2.0.  The packages in the database
are distinguished via a *package key*, which is an md5 hash of the
package id (e.g. q-1.0) and the sorted list of the package IDs of the
transitive closure of dependencies (e.g. p-1.0 or p-2.0).  The package
key is used to generate linker symbols for packages, so it's possible to
link together both copies of q in the same program, as long as you
rename the modules appropriately (of course, the redefined types are
considered unequal).  When registering a package, ghc-pkg now checks
and removes duplicate package keys, as opposed to package IDs.

I've also implemented many of the necessary niceties for making it
pleasant to deal with duplicated package IDs: for example, GHC's output
logic has been adjusted to only qualify a package ID with the package
key when there are multiples of the same package ID exposed in the
database.  I've also adjusted GHC's build system to use package keys
rather than package IDs to refer to packages when building.

Like the original GSoC project, we still need to have decisions on some
of the major design choices.  I think the most pressing one is
"simplistic dependency resolution" when you use, e.g. ghc -package
foo-1.0 or ./Setup configure --with-constraint="foo==1.0".  Right now, I
pick dependencies in an unspecified manner, check if they are
consistent, and bail out if they are not.  As it turns out, both
GHC and ./Setup configure will already compute the transitive closure of
dependencies, so I suspect we might be able to do something clever here.
Less pressing but eventually necessary is clueing in cabal-install.

Comments would be especially appreciated.

Cheers,
Edward

[1] https://phabricator.haskell.org/D80
[2] https://github.com/haskell/cabal/pull/2002