... | ... | @@ -121,7 +121,7 @@ We change installed package IDs and package keys in the following ways: |
|
|
|
|
|
<table><tr><th>Installed Package ID</th>
|
|
|
<td>
|
|
|
Hash of source code sdist tarball, selected Cabal flags (not the command line flags), GHC flags, IPIDs of direct dependencies. This brings IPIDs more inline with the concept of a \[NIX\] hash, which lets us truly uniquely identify builds of packages (whereas a package key may conclude two builds are the same, although their source has changed.) This is especially important if all sandboxed builds are being installed to the same location. The patch to make Cabal compute this is being tracked here: [ https://github.com/haskell/cabal/pull/2752](https://github.com/haskell/cabal/pull/2752)</td></tr></table>
|
|
|
Hash of source code sdist tarball, selected Cabal flags (not the command line flags), GHC flags, IPIDs of direct dependencies (the `build-depends` of the library in the Cabal file). This brings IPIDs more inline with the concept of a \[NIX\] hash, which lets us truly uniquely identify builds of packages (whereas a package key may conclude two builds are the same, although their source has changed.) This is especially important if all sandboxed builds are being installed to the same location. The patch to make Cabal compute this is being tracked here: [ https://github.com/haskell/cabal/pull/2752](https://github.com/haskell/cabal/pull/2752)</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Package Key</th>
|
|
|
<td>
|
... | ... | @@ -137,12 +137,12 @@ Backpack introduces the concept of a unit, which is a package-like code organiza |
|
|
An indefinite unit is a single unit which hasn't been instantiated; a definite unit is one that has an instantiation of its holes. Units without holes are both definite and indefinite (they can be used for both contexts).
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Indefinite unit record</th>
|
|
|
<table><tr><th>Indefinite unit record (in indefinite unit database)</th>
|
|
|
<td>
|
|
|
An indefinite unit record is the most general result of type-checking a unit without any of its holes instantiated. It is identified by an installed indefinite unit ID, and consists of the types of the modules in the unit (ModIfaces) as well as the source code of the unit (so that it can be recompiled into a definite unit). Indefinite unit records can be installed in the "indefinite unit database."
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Definite unit record (previously installed package record)</th>
|
|
|
<table><tr><th>Definite unit record (previously installed package record, in the definite unit database, previously the installed package database)</th>
|
|
|
<td>
|
|
|
A definite unit record is a fully-instantiated unit with its associated library. It is identified by an installed definite unit ID, and consists of the types and objects of the compiled unit; they also contain metadata for their associated package. Definite unit records can be installed in the "definite unit database" (previously known as the "installed package database.") If the unit is the distinguished unit for the package, this record also contains all of the metadata about the containing package.
|
|
|
</td></tr></table>
|
... | ... | @@ -155,14 +155,29 @@ To handle these, we need some new identifiers: |
|
|
Something like "p", a unit name is a source-level identifier which distinguishes the multiple units in a package; e.g. `unit p where ...` defines a unit with name `p`. The unit name that is the same as the containing package is special: it is the "public" unit that is externally accessible.
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>(Installed) Indefinite Unit ID</th>
|
|
|
<table><tr><th>(Installed) (Fully) Indefinite Unit ID</th>
|
|
|
<td>
|
|
|
Installed package ID and unit name which identifies the (transitive) source code of an indefinite unit. For non-Backpack units, the unit name is omitted.
|
|
|
Installed package ID and unit name, which identifies the (transitive) source code of an indefinite unit, Cabal flags, build flags, etc. For non-Backpack units, the unit name is omitted. Equivalently, an indefinite unit ID is a unit key such that for each hole mapping for A is to HOLE:A, e.g. `p(A -> HOLE:A, B -> HOLE:B)`.
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Unit Key (previously named Package Key; also known as an Installed Definite Unit ID)</th>
|
|
|
<table><tr><th>Unit Key (previously named Package Key)</th>
|
|
|
<td>
|
|
|
For Backpack units, the unit key is the indefinite unit ID plus a mapping from holes to modules (unit key plus module name). For non-Backpack units, the unit key is equivalent to the installed package ID (since there is no unit name, and the hole mapping is empty). These serve the role of \[SYMBOL, LIBRARY, TYPES\]
|
|
|
For Backpack units, the unit key is the indefinite unit ID plus a mapping from holes to modules (unit key plus module name). For non-Backpack units, the unit key is equivalent to the installed package ID (since there is no unit name, and the hole mapping is empty). There is also a distinguished key, called "HOLE". These serve the role of \[SYMBOL, LIBRARY, TYPES\]. (Partially definite unit keys can occur on-the-fly during type checking.)
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Hole Key</th>
|
|
|
<td>
|
|
|
The hole key is a distinguished unit key, which is for the "hole package", representing modules which are not yet implemented (there is not actually a unit named hole, it's just a notational convention).
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Installed (Fully) Definite Unit ID</th>
|
|
|
<td>
|
|
|
An installed definite unit ID, is a unit key, whose requirements are fully filled with installed definite unit IDs (transitively); alternately, it's just a unit key with no occurrences of the unit key HOLE, e.g. `p(A -> uid, B -> uid2)` where `uid` and `uid2` are fully definite unit IDs.
|
|
|
</td></tr></table>
|
|
|
|
|
|
<table><tr><th>Module</th>
|
|
|
<td>
|
|
|
A unit key plus a module name.
|
|
|
</td></tr></table>
|
|
|
|
|
|
## Features
|
... | ... | |