Age | Commit message (Collapse) | Author |
|
1. `DerivationOutput` now as the `std::variant` as a base class. And the
variants are given hierarchical names under `DerivationOutput`.
In 8e0d0689be797f9e42f9b43b06f50c1af7f20b4a @matthewbauer and I
didn't know a better idiom, and so we made it a field. But this sort
of "newtype" is anoying for literals downstream.
Since then we leaned the base class, inherit the constructors trick,
e.g. used in `DerivedPath`. Switching to use that makes this more
ergonomic, and consistent.
2. `store-api.hh` and `derivations.hh` are now independent.
In bcde5456cc3295061a0726881c3e441444dd6680 I swapped the dependency,
but I now know it is better to just keep on using incomplete types as
much as possible for faster compilation and good separation of
concerns.
|
|
This changes was taken from dynamic derivation (#4628). It` somewhat
undoes the refactors I first did for floating CA derivations, as the
benefit of hindsight + requirements of dynamic derivations made me
reconsider some things.
They aren't to consequential, but I figured they might be good to land
first, before the more profound changes @thufschmitt has in the works.
|
|
Also use std::string_view in a few more places.
|
|
once a string has been forced we already have dynamic storage allocated for it,
so we can easily reuse that storage instead of copying.
|
|
|
|
It was in the header but never implemented.
|
|
|
|
It isn't needed anymore now that don't need to eagerly resolve
everything like we used to do. So we can safely get rid of it
|
|
PRs #4370 and #4348 had a bad interaction in that the second broke the fist
one in a not trivial way.
The issue was that since #4348 the logic for detecting whether a
derivation output is already built requires some logic that was specific
to the `LocalStore`.
It happens though that most of this logic could be upstreamed to any `Store`,
which is what this commit does.
|
|
Rather than storing the derivation outputs as `drvPath!outputName` internally,
store them as `drvHashModulo!outputName` (or `outputHash!outputName` for
fixed-output derivations).
This makes the storage slightly more opaque, but enables an earlier
cutoff in cases where a fixed-output dependency changes (but keeps the
same output hash) − same as what we already do for input-addressed
derivations.
|
|
Let's get one step closer to the daemon not needing to fork.
|
|
|
|
|
|
|
|
so we can link outputs to deriver and thus properly cache.
|
|
|
|
We no longer need the `*Opt` to disambiguate.
|
|
If we resolve using the known path of a derivation whose output we
didn't have, we previously blew up. Now we just fail gracefully,
returning the map of all outputs unknown.
|
|
ca-floating-upstream
|
|
- More and better comments
- The easier renames
|
|
We will sometimes try to query the outputs of derivations we can't
resolve. That's fine; it just means we don't know what those outputs are
yet.
|
|
ca-floating-upstream
|
|
|
|
Revise division of labor in deserialization of derivations
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
|
|
|
|
|
|
Insead they should be opaque `/<hash>` like the placeholders we already
have.
|
|
derivation-header-include-order
|
|
|
|
Offer a safer interface for path and pathOpt
|
|
into single-ca-drv-build
|
|
The name is now stored with the derivation itself.
|
|
|
|
new-interface-for-path-pathOpt
|
|
This is the one non-prefixed occurence
|
|
|
|
derivation-header-include-order
|
|
The new interface we offer provides a way of getting all the
DerivationOutputs with the storePaths directly, based on the observation
that it's the most common usecase.
|
|
optional-derivation-output-storepath
|
|
|
|
It's a tiny function which is:
- hardly worth abstrating over, and also only used once.
- doesn't work once we get CA drvs
I rewrote the one callsite to be forwards compatable with CA
derivations, and also potentially more performant: instead of reading in
the derivation it can ust consult the SQLite DB in the common case.
|
|
into misc-ca
|
|
|
|
|
|
|
|
github.com:Ericson2314/nix into misc-ca
|
|
|
|
derivation-header-include-order
|