#10622: Rename Backpack packages to units -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D1057 -------------------------------------+------------------------------------- Old description:
After today's weekly Backpack call, we have come to the conclusion that we have two different types of "packages" in the Backpack world:
1. Cabal packages, which have a single `.cabal` file and are a unit of distribution which get uploaded to Hackage, and
2. Backpack packages, of which there may be multiple defined in a Backpack file shipped with a Cabal package; and are the building blocks for modular development in the small.
It's really confusing to have both of these called packages: thus, we propose to rename all occurrences of Backpack package to unit. A Cabal ''package'' may contain MULTIPLE Backpack ''units'', and old-style Cabal files will only define one unit. Every Cabal package has a distinguished unit (with the same name as the package) that serves as the publically visible unit.
A Cabal package remains * The unit of distribution * The unit that Hackage handles * The unit of versioning * The unit of ownership (who maintains it etc)
Here are some of the consequences:
1. The "installed package database" no longer maintains a one-to-one mapping between Cabal packages and entries in the database. This invariant is being dropped for two reasons: (1) With a Nix-style database, a package `foo-0.1` may be installed many times with different dependencies / source code, all of which live in the installed package database. (2) With Backpack, a package containing a Backpack file may install multiple units. To avoid having to rename *everything*, we'll keep calling this the installed package database, but really it's more like an installed *unit* database.
2. We rename `PackageKey` to `UnitKey`, as it identifies a unit rather than a Cabal package. (I think this actually makes the function of these identifiers clearer.) We'll also distinguish Cabal-file level `PackageName`s from Backpack-file `UnitName`s. Installed units continue to be identified by `InstalledPackageId`.
3. The source-level syntax of Backpack files will use `unit` in place of where `package` was used before.
4. For old-style packages, Cabal will continue to write and register a single entry in the installed package database. For Backpack packages, Cabal will register as many entries as is necessary to install a package. The entry with the same `UnitName` as `PackageName` is publically visible to other packages. If a Backpack file defines other packages, those packages are registered with different `UnitName`s (giving them different `InstalledPackageId`s) which are not publically visible. The non- publically visible packages will have their description/URL/etc fields blank, and have a pointer to the "real" package.
5. If when installing a unit, we discover that it is already present in the database, we check if the ABI hashes are the same. If they are, we simply skip installing the unit but otherwise proceed. If the ABI hashes are not the same, we error: the units we are installing need to be recompiled against the unit present in the database.
New description: After today's weekly Backpack call, we have come to the conclusion that we have two different types of "packages" in the Backpack world: 1. Cabal packages, which have a single `.cabal` file and are a unit of distribution which get uploaded to Hackage, and 2. Backpack packages, of which there may be multiple defined in a Backpack file shipped with a Cabal package; and are the building blocks for modular development in the small. It's really confusing to have both of these called packages: thus, we propose to rename all occurrences of Backpack package to unit. A Cabal ''package'' may contain MULTIPLE Backpack ''units'', and old-style Cabal files will only define one unit. Every Cabal package has a distinguished unit (with the same name as the package) that serves as the publically visible unit. A Cabal package remains * The unit of distribution * The unit that Hackage handles * The unit of versioning * The unit of ownership (who maintains it etc) Here are some of the consequences: 1. The "installed package database" no longer maintains a one-to-one mapping between Cabal packages and entries in the database. This invariant is being dropped for two reasons: (1) With a Nix-style database, a package `foo-0.1` may be installed many times with different dependencies / source code, all of which live in the installed package database. (2) With Backpack, a package containing a Backpack file may install multiple units. To avoid having to rename *everything*, we'll keep calling this the installed package database, but really it's more like an installed *unit* database. 2. We rename `PackageKey` to `UnitKey`, as it identifies a unit rather than a Cabal package. (I think this actually makes the function of these identifiers clearer.) We'll also distinguish Cabal-file level `PackageName`s from Backpack-file `UnitName`s. Installed units are identified by an `InstalledUnitId` instead of an `InstalledPackageId`. 3. The source-level syntax of Backpack files will use `unit` in place of where `package` was used before. 4. For old-style packages, Cabal will continue to write and register a single entry in the installed package database. For Backpack packages, Cabal will register as many entries as is necessary to install a package. The entry with the same `UnitName` as `PackageName` is publically visible to other packages. If a Backpack file defines other packages, those packages are registered with different `UnitName`s (giving them different `InstalledPackageId`s) which are not publically visible. The non- publically visible packages will have their description/URL/etc fields blank, and have a pointer to the "real" package. 5. If when installing a unit, we discover that it is already present in the database, we check if the ABI hashes are the same. If they are, we simply skip installing the unit but otherwise proceed. If the ABI hashes are not the same, we error: the units we are installing need to be recompiled against the unit present in the database. -- Comment (by ezyang): OK. (I was thinking about BC for Cabal users but I guess it should not be too bad. We'll see.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10622#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler