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-boun...@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@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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
