{"push_id":809691761,"size":1,"distinct_size":1,"ref":"refs/heads/cabal-to-pks","head":"77905fccd9b901590c0aef5213fd40a9d350fda1","before":"3d9270d816bcbcee7340fd451f073390cd42ffa1","commits":[{"sha":"77905fccd9b901590c0aef5213fd40a9d350fda1","author":{"email":"dbd597f5635f432486c5d365e9bb585b3eaa1853@cs.stanford.edu","name":"Edward Z. Yang"},"message":"Implement ComponentInstanceId, replacing PackageKey and InstalledPackageId.\n\nToday in Cabal, when you build and install a package, it is\nuniquely identified using an InstalledPackageId which is computed\nusing the ABI hash of the library that was installed.  There\nare few problems with doing it this way:\n\n    - In a Nix-like world, we should instead uniquely identify\n      build products by some sort of hash on the inputs to the\n      compilation (source files, dependencies, flags).  The ABI\n      hash doesn't capture any of this!\n\n    - An InstalledPackageId suggests that we can uniquely identify\n      build products by hashing the source and dependencies of\n      a package as a whole.  But Cabal packages contain many components:\n      a library, test suite, executables, etc.  Currently, when\n      we say InstalledPackageId, we are really just talking about\n      the dependencies of the library; however, this is unacceptable\n      if a Cabal package can install multiple libraries; we need\n      different identifiers for each.\n\n    - We've also needed to compute another ID, which we've called\n      the \"package key\", which is to be used for linker symbols\n      and type equality GHC-side.  It is confusing what the distinction\n      between this ID and InstalledPackageIds are; the main reason\n      we needed another ID was because the package key was needed\n      prior to compilation, whereas the ABI hash was only available\n      afterwards.\n\nThis patch replaces InstalledPackageId and PackageKey with a\nnew identifier called ComponentInstanceId, which has the following\nproperties:\n\n    - It is computed per-component, and consists of a package\n      name, package version, hash of the ComponentInstanceIds\n      of the dependencies it is built against, and the name\n      of the component.  For example, \"foo-0.1-abcdef\" continues\n      to identify the library of package foo-0.1, but\n      \"foo-0.1-123455-foo.exe\" would identify the executable,\n      and \"foo-0.1-abcdef-bar\" would identify a private sub-library\n      named bar.\n\n    - It is passed to GHC to be used for linker symbols and\n      type equality.  So as far as GHC is concerned, this is\n      the end-all be-all identifier.\n\n    - Cabal the library has a simple, default routine for computing\n      a ComponentInstanceId which DOES NOT hash source code;\n      in a later patch Duncan is working on, cabal-install can\n      specify a more detailed ComponentInstanceId for a package\n      to be built with.\n\nHere are some knock-on effects:\n\n    - 'id' is a ComponentInstanceId\n\n    - 'depends' is now a list of ComponentInstanceIds\n\n    - New 'abi' field to record what the ABI of a unit is (as it is no longer\n      computed by looking at the output of ghc --abi-hash).\n\n    - The 'HasInstalledPackageId' typeclass is renamed to\n      'HasComponentInstanceId'.\n\n    - GHC 7.10 has explicit compatibility handling with\n      a 'compatPackageKey' (an 'ComponentInstanceId') which is\n      in a compatible format.  The value of this is read out\n      from the 'key' field.\n\nSigned-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>","distinct":true,"url":"https://api.github.com/repos/ezyang/cabal/commits/77905fccd9b901590c0aef5213fd40a9d350fda1"}]}