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.
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.
Would it be better/worse to use stdenv's
passthru
for this instead of a//
update?I.e.
passthru = curPkgs
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.
From my testing this seems to do the exact same thing. I feel like
passthru
is a slightly nicer alternative to avoid potentially attrset shadowing from//
, not thatmkShellNoCC
andpkgs
have anything in common now, but maybe in the future?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.
They're similar, except for two differences:
pkg // foo
is not preserved in the return value ofpkg.overrideAttrs
or any other such functions that re-evaluate the package function//
is simple and not subject to changeFor these reasons I would
passthru
in cases where the new attributes relate strongly to the package (in this case the shell) and if the new attrs should be preserved in the return value ofoverrideAttrs
//
in cases where the addition is circumstantial. Another example would be testing a static build of a package in thetests
attribute. Usingpassthru
for that would create an expectation that overrides are applied to that test, but they're not, so it'd be better for such atests
test to be omitted afteroverrideAttrs
.In this case, calling
overrideAttrs
only needs to produce a shell, and not the whole package set, so we don't needpassthru
.I also think
//
is nicer because it makes it clear which attrset wins when there's a conflict; the shell, and we don't need to check howmkDerivation
works or test it to confirm.