-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Get rid of addWantedOutputs
#13240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Get rid of addWantedOutputs
#13240
Conversation
15d4fb0
to
3969fcb
Compare
DerivationCreationAndRealisationGoal
, get rid of addWantedOutputs
addWantedOutputs
3969fcb
to
8a9bde3
Compare
🎉 All dependencies have been resolved ! |
8a9bde3
to
a60ad96
Compare
static bool removeGoal(std::shared_ptr<G> goal, std::weak_ptr<G> & gp) | ||
{ | ||
/* !!! inefficient */ | ||
cullMap(goalMap, [&](const std::weak_ptr<G> & gp) -> bool { | ||
return gp.lock() != goal; | ||
}); | ||
return gp.lock() != goal; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit strange that removeGoal
does't actually remove anything now. Maybe something like shouldRemoveGoal
is more fitting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it has to have the same as the others for overloading/recursion reasons.
src/libstore/include/nix/store/build/derivation-creation-and-realisation-goal.hh
Outdated
Show resolved
Hide resolved
0ec0229
to
a8965c5
Compare
We move the `assertPathValidity` to where we know what the wanted outputs are.
Do this by introducing `DerivationTrampolineGoal`. `DerivationGoal` now only tracks a single output, and is back to tracking a plain store path `drvPath`, not a deriving path one. Its `addWantedOutputs` method is gone. These changes will allow subsequent PRs to simplify it greatly. Because the purpose of each goal is back to being immutable, we can also once again make `Goal::buildResult` a public field, and get rid of the `getBuildResult` method. This simplifies things also. `DerivationTrampolineGoal` is, as the nane is supposed to indicate, a cheap "trampoline" goal. It takes immutable sets of wanted outputs, and just kicks of `DerivationGoal`s for them. Since now "actual work" is done in these goals, it is not wasteful to have separate ones for separate sets of outputs, even if those outputs (and the derivations they are from) overlap. This design is described in more detail in the doc comments on the goal types, which I've now greatly expanded. --- This separation of concerns will make it possible for future work on issues like NixOS#11928, and to continue the path of having more goal types, but each goal type does fewer things (issue NixOS#12628). --- This commit in some sense reverts f4f28cd, but that one kept around `addWantedOutputs`. I am quite sure it was having two layers of goals with `addWantedOutputs` that caused the issues --- restarting logic like `addWantedOutputs` has is very tempermental! In this version of the change, we have *zero* layers of `addWantedOutputs` --- no goal type needs it, or otherwise has a mutable objective --- and so I think this change is safe. Co-authored-by: Sergei Zimmerman <145775305+xokdvium@users.noreply.github.com>
a8965c5
to
2ff8cbc
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2025-05-28-nix-team-meeting-minutes-229/65205/1 |
Motivation
Do this by introducing
DerivationTrampolineGoal
.DerivationGoal
now only tracks a single output, and is back to tracking a plain store pathdrvPath
, not a deriving path one. ItsaddWantedOutputs
method is gone. These changes will allow subsequent PRs to simplify it greatly.Because the purpose of each goal is back to being immutable, we can also once again make
Goal::buildResult
a public field, and get rid of thegetBuildResult
method. This simplifies things also.DerivationTrampolineGoal
is, as the nane is supposed to indicate, a cheap "trampoline" goal. It takes immutable sets of wanted outputs, and just kicks ofDerivationGoal
s for them. Since now "actual work" is done in these goals, it is not wasteful to have separate ones for separate sets of outputs, even if those outputs (and the derivations they are from) overlap.This design is described in more detail in the doc comments on the goal types, which I've now greatly expanded.
Context
This separation of concerns will make it possible for future work on issues like #11928, and to continue the path of having more goal types, but each goal type does fewer things (issue #12628).
This commit in some sense reverts f4f28cd, but that one kept around
addWantedOutputs
. I am quite sure it was having two layers of goals withaddWantedOutputs
that caused the issues --- restarting logic likeaddWantedOutputs
has is very tempermental! In this version of the change, we have zero layers ofaddWantedOutputs
--- no goal type needs it, or otherwise has a mutable objective --- and so I think this change is safe.depends on #13186
depends on #13294
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.