ghc-pkg package config validation too strict
Registration of a package using the following config works:
name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base-18.104.22.168:Data.Bool, Foo from base-22.214.171.124:Data.List, Frob depends: base-126.96.36.199
But while GHC is happy to work with the following variant of the above configuration added by hand to the package database, it's not possible to add it via
ghc-pkg register, because it's rejected at validation phase:
name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base:Data.Bool, Foo from base:Data.List, Frob depends: base
We get the following error:
$ ghc-pkg register frob.conf frob-0.1.0.0: module reexport refers to a non-existent defining package: base (use --force to override)
This is unfortunate, because in general unit-id's don't just have version numbers but also hashes, and in some settings these can be hard to guess.
The general point is that ghc-pkg should be exactly as permissive as GHC itself, not less or more. One way to achieve that is to make the
checkModule function in
utils/ghc-pkg/Main.hs (called by
lookupPackageName as a fallback to
lookupUnitId, and say that if
lookupPackageName returns exactly one result (i.e. the name is unambiguous) then that should be considered okay. Perhaps not A-okay, because the name could become ambiguous in the future when more entries are added to the database, but that should at most be a warning, not an error, I think.
Note: in principle we should be able to use the
--force flag here to bypass the results of configuration validation. But oddly enough,
--force filters out entries that it objects about, rather than just letting them pass through. So
--force is not a workable workaround.