Use DerivedPath for buildPaths and ensurePath
#4594
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ericson2314
force-pushed
the
lots-of-buildable
branch
from
10c0402 to
79e5467
Compare
Ericson2314
changed the title
BuildableReq for buildPaths and ensurePathBuildableReq for buildPaths and ensurePath
This was referenced Mar 6, 2021
Ericson2314
force-pushed
the
lots-of-buildable
branch
from
1f5a011 to
5219500
Compare
In the following commits it will become less prevalent.
These are by no means part of the notion of a store, but rather are things that happen to use stores. (Or put another way, there's no way we'd make them virtual methods any time soon.) It's better to move them out of that too-big class then. Also, this helps us remove StorePathWithOutputs from the Store interface altogether next commit.
This avoids an ambiguity where the `StorePathWithOutputs { drvPath, {}
}` could mean "build `brvPath`" or "substitute `drvPath`" depending on
context.
It also brings the internals closer in line to the new CLI, by
generalizing the `Buildable` type is used there and makes that
distinction already.
In doing so, relegate `StorePathWithOutputs` to being a type just for
backwards compatibility (CLI and RPC).
This makes for better types errors and allows us to give it methods.
This allows us to namespace its constructors under it.
Ericson2314
force-pushed
the
lots-of-buildable
branch
from
5219500 to
125a824
Compare
Ericson2314
changed the title
BuildableReq for buildPaths and ensurePathDerivedPath for buildPaths and ensurePath
matthewbauer
added a commit
to matthewbauer/nix
that referenced
this pull request
May 5, 2021
This was previously done in NixOS#4515 but got clobbered away in NixOS#4594. -------------------------------------------------------------------------------- This fixes an issue where derivations with a primary output that is not "out" would fail with: $ nix profile install nixpkgs#sqlite error: opening directory '/nix/store/2a2ydlgyydly5czcc8lg12n6qqkfz863-sqlite-3.34.1-bin': No such file or directory This happens because while derivations produce every output when built, you might not have them if you didn't build the derivation yourself (for instance, the store path was fetch from a binary cache). This uses outputName provided from DerivationInfo which appears to match the first output of the derivation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
his avoids an ambiguity where the
StorePathWithOutputs { drvPath, {} }could mean "buildbrvPath" or "substitutedrvPath" depending on context.It also brings the internals closer in line to the new CLI, by generalizing the
Buildabletype is used there and makes that distinction already.In doing so, relegate
StorePathWithOutputsto being a type just for backwards compatibility (CLI and RPC).BuildGoal,BuildGoalWithOptOutputName? I went withDerivedPath