Renaming InstalledPackageId

Fri Sep 18 09:22:12 UTC 2015

Good idea!

| suggestions.  I might also be convinced by "InstalledComponentId" (which

I dislike the "installed" part for the reasons you say.  And I would really love to have some indication that this is a hash or MD5 sum of the entire INPUT to the compilation process (source code, flags...).   That's why I liked ComponentSourceHash; the "source" stresses input; the "hash" connotes the idea of summarising all the source code transitively.

Simon

| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of
| Edward Z. Yang
| Sent: 18 September 2015 04:33
| To: cabal-devel; ghc-devs
| Subject: Renaming InstalledPackageId
| 
| Hello friends,
| 
| During discussions with many people about Nix-like Cabal, it has emerged
| that InstalledPackageId is /really/ bad name.  Consider: the commonly
| accepted definition of an InstalledPackageId in Nix is that it is
| morally a hash of all the inputs to compilation: the source code, the
| dependencies of the package, and the build configuration.  However, a
| Cabal package can have *multiple* components (e.g. the library, the test
| suite, etc), each of which has its own 'build-depends' field. The
| concept of the "dependencies of a package" is simply not well-defined!
| 
| The "simplification" that Cabal has adopted for a long time is to say
| that the installed package ID always refers to the library component of
| a package. [1]  But the name InstalledPackageId has caused countless
| misunderstandings about how dependency resolution is done, even in Cabal's
| code. [2]
| 
| I propose that we change the name of InstalledPackageId.  The new
| name should have the following properties:
| 
| 1. It should not say anything about packages, because it is not
| well-defined for a package, e.g. it should be something like
| "ComponentId".
| 
| 2. It should not say anything about installation, because it is
| well-defined even before a package is even built.
| 
| 3. It should some how communicate that it is a hash of the transitive
| source code (e.g. including dependencies) as well as build parameters.
| SPJ likes "SourceHash" because it's evocative of this (though I don't
| like it as much); there may also be a Nix-y term like "Derivation" we
| can use here.
| 
| My proposed new name is "ComponentBuildHash", however I am open to other
| suggestions.  I might also be convinced by "InstalledComponentId" (which
| runs aground (2) but is fairly similar to the old name, and gains points
| for familiarity.)  However, I would like to hear your comments: have a
| better name? Think this is unnecessary? Please let me know.
| 
| Edward
| 
| P.S. With Backpack, the ComponentBuildHash won't even be the primary key
| into the installed package (to be renamed to a component/unit) database,
| because a single ComponentBuildHash can be rebuilt multiple times with
| different instantiations of its holes.  So GHC will have some
| identifier, which we will probably continue to call the 'UnitKey', which
| is the ComponentBuildHash (entirely Cabal generated) plus extra
| information about how holes are instantiated (entirely GHC generated).
| 
| [1] Except when it doesn't: cabal-install currently merges all the
| dependencies
| of all components that are being built for a package together and treats
| that as the sum total dependencies of the package.  This causes problems
| when the test suite for text depends on a testing library which in turn
| depends on text, c.f.
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f960&data=01%7c01%7csimonpj%40064d.mgd.micro
| soft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011
| db47%7c1&sdata=3sQjxpWQccNyIR43FYonKTAQ3ENahciXLKtauzLKyXk%3d
| 
| [2] Here are some bugs caused by confusion of package dependencies
| versus component dependency:
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f2802&data=01%7c01%7csimonpj%40064d.mgd.micr
| osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01
| 1db47%7c1&sdata=hcGUnJdwYz9GkKILhc8u9qgQrxTkcGUAqpd6VgW7k5I%3d Specify
| components when configuring, not building
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f2623&data=01%7c01%7csimonpj%40064d.mgd.micr
| osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01
| 1db47%7c1&sdata=QcllkUWL%2bTakINFCnty%2f30UsFDtb6y4NaNHa72Sy28Y%3d `-j`
| should build package components in parallel
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f1893&data=01%7c01%7csimonpj%40064d.mgd.micr
| osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01
| 1db47%7c1&sdata=NnRigIN%2fI%2fVrFgpjhZr7TaavIIdom1JBldlw4wlvpyA%3d Use
| per-component cabal_macros.h
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f1575&data=01%7c01%7csimonpj%40064d.mgd.micr
| osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01
| 1db47%7c1&sdata=xakCm5et0uCGy9TxCoL5GfosGQfGdytzFXGX92Tqe3o%3d Do
| dependency resolution on a per component basis
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f1768&data=01%7c01%7csimonpj%40064d.mgd.micr
| osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01
| 1db47%7c1&sdata=GCMmO3OZbl9RXswxeVd2d5%2bTu9eQ7DqhNyqwePvg9x0%3d The
| "benchmark" target dependencies conflict with "executable" targets
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co
| m%2fhaskell%2fcabal%2fissues%2f960&data=01%7c01%7csimonpj%40064d.mgd.micro
| soft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011
| db47%7c1&sdata=3sQjxpWQccNyIR43FYonKTAQ3ENahciXLKtauzLKyXk%3d Can't build
| with --enable-tests in presence of circular dependencies
| _______________________________________________
| cabal-devel mailing list
| cabal-devel at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fcabal-
| devel&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cee169cf81c354b8200
| d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0k73G6r0wXJ5qA
| HcrbUqpUjKaWvLuEXR%2fQAwF2XwH6c%3d