GitLab

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The parsePackageIndex wasn't streaming because resulting list was
hidden in two constructors: Either and tuple. By removing that error
semantics changed in updatePackageIndexCacheFile.

The updatePackageIndexCacheFile problem was sequence call that evaluated
whole list made by parsePackageIndex. By using lazySequence any error
during index file parsing will be raised during writing to cache file.

Also removed reacPackageIndexFile, as it wasn't used anywhere as far as
I can tell. If this is a mistake I'll include it again.

Duncan Coutts authored Jul 22, 2015 and Mikhail Glushenkov committed Jul 30, 2015

No longer needed anywhere else.

The existing code supports reading multiple preferred-versions files in
the 00-index.tar and merging them. However it doesn't do it quite right
when the same file is updated, it merged them instead of the later one
overriding the first.

This should make no difference right now because the 00-index.tar
typically only contains a single preferred-versions file, with no
updates.

Say 16 days, rather than 16.3 days. The precision is quite unnecessary.

Fixes #2060.

* The function has type 'Repo -> IO Double'.
* It returns the age in days as a Double.
* Places that expected the age as an Int have been updated.
* Builds with ghc 7.4.2 and 7.8.3.

BC note: renamed type PackageIndex :: * to InstalledPackageIndex.

The intent is to have cabal-install use this package index in order to
track information about compilation in progress.  We introduce a new
PackageInstalled type-class to keep track of data types which have their
IDs and dependency graphs in InstalledPackageId.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

It looks like #1443 was actually fixed by the change from getModificationTime to
getModTime (which has higher resolution). The change to '>=' was not needed
because the code uses 'when', not 'unless'.

Thanks to Nikita Karetnikov for the heads-up.

Particularly when dealing with add-source dependencies, it is useful to know
in which directory cabal can't find a .cabal file, see:
https://github.com/haskell/cabal/issues/1816

Errors are also improved when installing local packages, e.g. `cabal install
another/directory`.

Avoid inline strings and manual spacing - use already-declared key variables
and unwords

Make 'findPackageDesc' return an 'Either'.

Comparison was using (>) instead of (>=). Bug introduced in 272a5c2c.
Fixes #1443.

Helps to disambiguate Cabal's compat modules from cabal-install's.

Snapshot deps now behave more like `cabal-dev add-source`. Implemented by adding
a BuildTreeRefType field to the BuildRef index entry.

Fixes #1321.

refold authored May 01, 2013 and Mikhail Glushenkov committed May 02, 2013

Since we're using 'unless' here, we should use (>) instead of (>=).

Apparently, lazy I/O was involved after all. 'openFile' instead of 'withFile'
was deliberate - see the use of 'unsafeInterleaveIO' in
'packageIndexFromCache'. Fixed by adding a strict version of 'getSourceFiles'.

(patch manually merged into the cabal-1.16 branch)

This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.

This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.