The Cabal Nix GSOC is planning to change installed package IDs to be the hash of the sdist tarball of an package (instead of the ABI hash of the compiled code). https://ghc.haskell.org/trac/ghc/wiki/Commentary/GSoC_Cabal_nix Once we do this, SPJ and I propose to GET RID of package keys, removing a nettlesome source of indirection from Cabal and GHC. Here are the details:

Currently, GHC has two notions of package identity: the installed package ID (presently the ABI hash) which uniquely identifies a package in the installed package database, and the package key, which is used for linker symbols and type identity. In fact, package keys are a COARSE version of installed package IDs: they contain information about the transitive dependencies Cabal picked, but not any details about the actual source code. (Put alternately: if the package key changes, the installed package ID changes, but not vice versa.)

Why do we have a fine-grained notion of identity, and a coarse-grained version? Historically, there were two reasons:

1. The installed package ID was computed with ghc --abi-hash after compilation, where as the package key needed to be passed to GHC before compilation; and
2. When developing a package, it seemed desirable to not recompile whenever source changed, which is what would occur if the package key were based on a hash of the sdist.

(1) is no longer applicable when installed package IDs are computed by hasing sdist. And (2) can be addressed simply by picking STABLE, fake installed package IDs when doing local development; e.g. "containers-2.0-inplace". If you want to install to the global database, you'll have to recompile everything with the right IPIDs, but for inplace development this should work great.