runPhase
subshell and exit status
#363423
Draft
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.
This PR follows up on #330751, modifying the
runPhase
function to be more useful for command chaining and scripting in devshells. I will restate the context below so this PR is self-sufficient, but newcomers are encouraged to review that PR and comment thread for additional context.The relatively new
runPhase
function in stdenv seems to be the best practice for building packages within a devshell, rather than manually executing sub-commands (e.g.,cmake .. && make
). This creates better consistency between dev workflow and the eventual realized derivation created bynix build
.However, the
runPhase
command obscures any failures which take place within the individual build phases. To fix that problem, this PR sets the errexit /set -e
shell option so that errors within simple commands, lists, or compound commands in the individual build phases will cause the phase to exit immediately, and causerunPhase
to return non-zero. This is consistent with the behavior of the stdenv builder which uses theset -e
option.A subshell is used to prevent setting the errexit option in the devshell, causing the devshell to exit on failure, which is generally not preferred.
This allows workflows like chaining commands in lists (e.g.,
runPhase configurePhase && runPhase buildPhase
) or scripting phases in the devshell (trivial example:runPhase buildPhase && echo "Succeeded" || echo "Failure"
).Caveat: using a subshell means that phases cannot modify variables in the devshell, which could be breaking or could (?) be beneficial. I'll convert this PR to "Ready for Review" once this is better understood.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.