fetchcargo: use flat tar.gz file for vendored src instead of recursive hash dir #78495
+47
−35
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 has several advantages:
substitute --flat hashes on single files (not recursive directory hashes).
fetchurl
src derivations work.package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like
${src}/etc/index.html
. Likewise, inthe store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on
verifyCargoDeps
, since both of them are relatively newly implementedbehavior that change the
cargoSha256
.If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the
cargoSha256
s.Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)