Rename to "content-address*ing* derivation"

"content-address*ed*" derivation is misleading because all derivations
are *themselves* content-addressed. What may or may not be
content-addressed is not derivation itself, but the *output* of the
derivation.

The outputs are not *part* of the derivation (for then the derivation
wouldn't be complete before we built it) but rather separate entities
produced by the derivation.

"content-adddress*ed*" is not correctly because it can only describe
what the derivation *is*, and that is not what we are trying to do.

"content-address*ing*" is correct because it describes what the
derivation *does* --- it produces content-addressed data.

doc/manual/redirects.js

@@ -375,6 +375,7 @@ const redirects = {
   "glossary.html": {
     "gloss-local-store": "store/types/local-store.html",
     "gloss-chroot-store": "store/types/local-store.html",
+    "gloss-content-addressed-derivation": "#gloss-content-addressing-derivation",
   },
 };
 

doc/manual/source/command-ref/nix-store/realise.md

@@ -15,7 +15,7 @@ Each of *paths* is processed as follows:
   1. If it is not [valid], substitute the store derivation file itself.
   2. Realise its [output paths]:
     - Try to fetch from [substituters] the [store objects] associated with the output paths in the store derivation's [closure].
-      - With [content-addressed derivations] (experimental):
+      - With [content-addressing derivations] (experimental):
         Determine the output paths to realise by querying content-addressed realisation entries in the [Nix database].
     - For any store paths that cannot be substituted, produce the required store objects:
       1. Realise all outputs of the derivation's dependencies
@@ -32,7 +32,7 @@ If no substitutes are available and no store derivation is given, realisation fa
 [store objects]: @docroot@/store/store-object.md
 [closure]: @docroot@/glossary.md#gloss-closure
 [substituters]: @docroot@/command-ref/conf-file.md#conf-substituters
-[content-addressed derivations]: @docroot@/development/experimental-features.md#xp-feature-ca-derivations
+[content-addressing derivations]: @docroot@/development/experimental-features.md#xp-feature-ca-derivations
 [Nix database]: @docroot@/glossary.md#gloss-nix-database
 
 The resulting paths are printed on standard output.

doc/manual/source/development/testing.md

@@ -164,7 +164,7 @@ $ checkPhase
 
 Sometimes it is useful to group related tests so they can be easily run together without running the entire test suite.
 Each test group is in a subdirectory of `tests`.
-For example, `tests/functional/ca/meson.build` defines a `ca` test group for content-addressed derivation outputs.
+For example, `tests/functional/ca/meson.build` defines a `ca` test group for content-addressing derivation outputs.
 
 That test group can be run like this:
 

doc/manual/source/glossary.md

@@ -13,7 +13,7 @@
 
     - [Content-Addressing File System Objects](@docroot@/store/file-system-object/content-address.md)
     - [Content-Addressing Store Objects](@docroot@/store/store-object/content-address.md)
-    - [content-addressed derivation](#gloss-content-addressed-derivation)
+    - [content-addressing derivation](#gloss-content-addressing-derivation)
 
   Software Heritage's writing on [*Intrinsic and Extrinsic identifiers*](https://www.softwareheritage.org/2020/07/09/intrinsic-vs-extrinsic-identifiers) is also a good introduction to the value of content-addressing over other referencing schemes.
 
@@ -69,7 +69,7 @@
 
   [realise]: #gloss-realise
 
-- [content-addressed derivation]{#gloss-content-addressed-derivation}
+- [content-addressing derivation]{#gloss-content-addressing-derivation}
 
   A derivation which has the
   [`__contentAddressed`](./language/advanced-attributes.md#adv-attr-__contentAddressed)
@@ -134,7 +134,7 @@
 - [input-addressed store object]{#gloss-input-addressed-store-object}
 
   A store object produced by building a
-  non-[content-addressed](#gloss-content-addressed-derivation),
+  non-[content-addressed](#gloss-content-addressing-derivation),
   non-[fixed-output](#gloss-fixed-output-derivation)
   derivation.
 
@@ -142,7 +142,7 @@
 
   A [store object] which is [content-addressed](#gloss-content-address),
   i.e. whose [store path] is determined by its contents.
-  This includes derivations, the outputs of [content-addressed derivations](#gloss-content-addressed-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
+  This includes derivations, the outputs of [content-addressing derivations](#gloss-content-addressing-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
 
   See [Content-Addressing Store Objects](@docroot@/store/store-object/content-address.md) for details.
 

doc/manual/source/store/drv.md

@@ -68,7 +68,7 @@ type OutputPath = {
 type DerivingPath = ConstantPath | OutputPath;
 ```
 
-Deriving paths are necessary because, in general and particularly for [content-addressed derivations][content-addressed derivation], the [store path] of an [output] is not known in advance.
+Deriving paths are necessary because, in general and particularly for [content-addressing derivations][content-addressing derivation], the [store path] of an [output] is not known in advance.
 We can use an output deriving path to refer to such an out, instead of the store path which we do not yet know.
 
 [deriving path]: #deriving-path
@@ -122,7 +122,7 @@ Nix can schedule builds such that it automatically builds on other platforms by
 
 [`system` configuration option]: @docroot@/command-ref/conf-file.md#conf-system
 
-[content-addressed derivation]: @docroot@/glossary.md#gloss-content-addressed-derivation
+[content-addressing derivation]: @docroot@/glossary.md#gloss-content-addressing-derivation
 [realise]: @docroot@/glossary.md#gloss-realise
 [store object]: @docroot@/store/store-object.md
 [store path]: @docroot@/store/store-path.md

src/libexpr-tests/nix_api_expr.cc

@@ -172,7 +172,7 @@ TEST_F(nix_api_expr_test, nix_expr_realise_context_bad_build)
 
 TEST_F(nix_api_expr_test, nix_expr_realise_context)
 {
-    // TODO (ca-derivations): add a content-addressed derivation output, which produces a placeholder
+    // TODO (ca-derivations): add a content-addressing derivation output, which produces a placeholder
     auto expr = R"(
         ''
             a derivation output: ${

src/libstore/build/derivation-goal.cc

@@ -1222,7 +1222,7 @@ SingleDrvOutputs DerivationGoal::registerOutputs()
        to do anything here.
 
        We can only early return when the outputs are known a priori. For
-       floating content-addressed derivations this isn't the case.
+       floating content-addressing derivations this isn't the case.
      */
     return assertPathValidity();
 }

src/libstore/ca-specific-schema.sql

@@ -1,4 +1,4 @@
--- Extension of the sql schema for content-addressed derivations.
+-- Extension of the sql schema for content-addressing derivations.
 -- Won't be loaded unless the experimental feature `ca-derivations`
 -- is enabled
 

src/libstore/daemon.cc

@@ -593,7 +593,7 @@ static void performOp(TunnelLogger * logger, ref<Store> store,
 
         auto drvType = drv.type();
 
-        /* Content-addressed derivations are trustless because their output paths
+        /* Content-addressing derivations are trustless because their output paths
            are verified by their content alone, so any derivation is free to
            try to produce such a path.
 

src/libstore/derivations.cc

@@ -300,7 +300,7 @@ static DerivationOutput parseDerivationOutput(
         } else {
             xpSettings.require(Xp::CaDerivations);
             if (pathS != "")
-                throw FormatError("content-addressed derivation output should not specify output path");
+                throw FormatError("content-addressing derivation output should not specify output path");
             return DerivationOutput::CAFloating {
                 .method = std::move(method),
                 .hashAlgo = std::move(hashAlgo),

src/libstore/derivations.hh

@@ -187,7 +187,7 @@ struct DerivationType {
     };
 
     /**
-     * Content-addressed derivation types
+     * Content-addressing derivation types
      */
     struct ContentAddressed {
         /**

src/libstore/remote-store.cc

@@ -608,7 +608,7 @@ void RemoteStore::queryRealisationUncached(const DrvOutput & id,
         auto conn(getConnection());
 
         if (GET_PROTOCOL_MINOR(conn->protoVersion) < 27) {
-            warn("the daemon is too old to support content-addressed derivations, please upgrade it to 2.4");
+            warn("the daemon is too old to support content-addressing derivations, please upgrade it to 2.4");
             return callback(nullptr);
         }
 

src/libstore/store-api.hh

@@ -715,7 +715,7 @@ public:
 
     /**
      * Given a store path, return the realisation actually used in the realisation of this path:
-     * - If the path is a content-addressed derivation, try to resolve it
+     * - If the path is a content-addressing derivation, try to resolve it
      * - Otherwise, find one of its derivers
      */
     std::optional<StorePath> getBuildDerivationPath(const StorePath &);

src/libstore/unix/build/local-derivation-goal.cc

@@ -800,7 +800,7 @@ void LocalDerivationGoal::startBuilder()
            out. */
         for (auto & i : drv->outputsAndOptPaths(worker.store)) {
             /* If the name isn't known a priori (i.e. floating
-               content-addressed derivation), the temporary location we use
+               content-addressing derivation), the temporary location we use
                should be fresh.  Freshness means it is impossible that the path
                is already in the sandbox, so we don't need to worry about
                removing it.  */
@@ -2291,7 +2291,7 @@ SingleDrvOutputs LocalDerivationGoal::registerOutputs()
        to do anything here.
 
        We can only early return when the outputs are known a priori. For
-       floating content-addressed derivations this isn't the case.
+       floating content-addressing derivations this isn't the case.
      */
     if (hook)
         return DerivationGoal::registerOutputs();

src/libstore/unix/build/local-derivation-goal.hh

@@ -130,7 +130,7 @@ struct LocalDerivationGoal : public DerivationGoal
      *   rewrite after the build. Otherwise the regular predetermined paths are
      *   put here.
      *
-     * - Floating content-addressed derivations do not know their final build
+     * - Floating content-addressing derivations do not know their final build
      *   output paths until the outputs are hashed, so random locations are
      *   used, and then renamed. The randomness helps guard against hidden
      *   self-references.

src/nix-store/nix-store.cc

@@ -252,7 +252,7 @@ static StorePathSet maybeUseOutputs(const StorePath & storePath, bool useOutput,
             return store->queryDerivationOutputs(storePath);
         for (auto & i : drv.outputsAndOptPaths(*store)) {
             if (!i.second.second)
-                throw UsageError("Cannot use output path of floating content-addressed derivation until we know what it is (e.g. by building it)");
+                throw UsageError("Cannot use output path of floating content-addressing derivation until we know what it is (e.g. by building it)");
             outputs.insert(*i.second.second);
         }
         return outputs;

tests/functional/ca/content-addressed.nix

@@ -16,7 +16,7 @@ in
 {
   seed ? 0,
 }:
-# A simple content-addressed derivation.
+# A simple content-addressing derivation.
 # The derivation can be arbitrarily modified by passing a different `seed`,
 # but the output will always be the same
 rec {

tests/functional/ca/derivation-json.sh

@@ -12,7 +12,7 @@ drvPath2=$(nix derivation add < "$TEST_HOME"/simple.json)
 
 [[ "$drvPath" = "$drvPath2" ]]
 
-# Content-addressed derivations can be renamed.
+# Content-addressing derivations can be renamed.
 jq '.name = "foo"' < "$TEST_HOME"/simple.json > "$TEST_HOME"/foo.json
 drvPath3=$(nix derivation add --dry-run < "$TEST_HOME"/foo.json)
 # With --dry-run nothing is actually written

tests/functional/dyn-drv/old-daemon-error-hack.nix

@@ -1,6 +1,6 @@
 with import ./config.nix;
 
-# A simple content-addressed derivation.
+# A simple content-addressing derivation.
 # The derivation can be arbitrarily modified by passing a different `seed`,
 # but the output will always be the same
 rec {

tests/functional/dyn-drv/text-hashed-output.nix

@@ -1,6 +1,6 @@
 with import ./config.nix;
 
-# A simple content-addressed derivation.
+# A simple content-addressing derivation.
 # The derivation can be arbitrarily modified by passing a different `seed`,
 # but the output will always be the same
 rec {