buildGoModule: Fix overriding with overlay-style stdenv#225051
buildGoModule: Fix overriding with overlay-style stdenv#225051doronbehar merged 2 commits intoNixOS:stagingfrom
Conversation
There was a problem hiding this comment.
It may not be a breaking change but I think we're to close to branch off for this so I'm a very strongly against including it in 23.05.
Also, I am planning to make a few changes to buildGoModule after the branch, e.g. drop vendorSha256 and only have vendorHash, it'll be easier and make this PR simpler if that happens first.
cc @NixOS/golang
Agree. Should I drop change to the the release note? I place them there just because the new release note hasn't come out yet. |
|
Would it be okay to just remove those |
Fine to leave them there for now, can be moved once the new release note is created after branch off.
Maybe, have to give it some thought first. Also, I'd appreciate it if you would revert all of the unrelated formatting changes, it makes the diff much harder to review. |
eeb5844 to
0e87a61
Compare
It turns out that the indentation difference is not just caused by Even then, I managed to make them align by making reasonable adjustment to the original expression (mainly by simplifying the The last commit contains the actual change. The relation between the original implementation and the new implementation can be seen from the diff. The expected attributes are organized at the beginning of the expression, and the corresponding comment documentation are prefixed with |
0e87a61 to
bd74d74
Compare
|
@ShamrockLee I'm switching this back to draft as it isn't going to be merged until after branch off. |
|
Still needs more testing but I've opened a PR to (mostly) get rid of vendorSha256. |
|
Go packages built with this buildGoModule implementation seems to take noticable longer to evaluate. Not sure if it also happens to #171586. How can we benchmark the evaluation time? |
bd74d74 to
fee7aae
Compare
There was a problem hiding this comment.
Sorry for causing the confusion.
No worries :).
In my imagination, the first overriding targeting
goModulesmight be buried somewhere inside the codebase, while another user made another overriding and setvendorHash = null.The purpose of this documentation is to avoid the conflicts between these overridings.
Hmm this is a bit complicated for at this point, so I'm still not sure I understand. Let's ask this: Why not:
| let | |
| pet-foo = pkgs.overrideAttrs ( | |
| finalAttrs: previousAttrs: { | |
| passthru = previousAttrs.passthru // { | |
| overrideModAttrs = lib.composeExtensions previousAttrs.passthru.overrideModAttrs ( | |
| finalModAttrs: previousModAttrs: { | |
| # goModules-specific overriding goes here | |
| postBuild = '' | |
| # Here you have access to the `vendor` directory. | |
| substituteInPlace vendor/github.com/example/repo/file.go \ | |
| --replace-fail "panic(err)" "" | |
| ''; | |
| } | |
| ); | |
| }; | |
| } | |
| ); | |
| pet-vendored = pet-foo.overrideAttrs { vendorHash = null; }; | |
| in | |
| pet-vendored | |
| let | |
| pet-foo = pkgs.overrideAttrs ( | |
| finalAttrs: previousAttrs: { | |
| # TODO: Explain this? | |
| vendorHash = null; | |
| passthru = previousAttrs.passthru // { | |
| overrideModAttrs = lib.composeExtensions previousAttrs.passthru.overrideModAttrs ( | |
| finalModAttrs: previousModAttrs: { | |
| # goModules-specific overriding goes here | |
| postBuild = '' | |
| # Here you have access to the `vendor` directory. | |
| substituteInPlace vendor/github.com/example/repo/file.go \ | |
| --replace-fail "panic(err)" "" | |
| ''; | |
| } | |
| ); | |
| }; | |
| } | |
| ); | |
| in | |
| pet-foo |
There was a problem hiding this comment.
Let's avoid the confusion by removing vendorHash = null and leaving it as a simple example demonstrating the correct overriding approach.
bea7e1a to
1d618a3
Compare
doronbehar
left a comment
There was a problem hiding this comment.
Excellent work! Thanks for working on this @ShamrockLee . I will give a few days for @zowoq a few more days to respond to this (it seemed they didn't like it initially), and if there will be no reply I'll merge this.
Fix overriding of vendorHash and various attributes via the fixed point attribute support of stdenv.mkDerivation. Pass as derivation attributes goModules, modRoot, vendorHash, deleteVendor, and proxyVendor. Move goModules and vendorHash out of passthru. Co-authored-by: Doron Behar <doron.behar@gmail.com>
1d618a3 to
eed069a
Compare
|
The package in the overriding example in |
Haven't responded to any of the new changes happened to the PR recently.
rl-2411.section.md: fix typo from #225051
|
The The parentheses ought to be curly braces. I've opened PR #336061 to fix it. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/overrideattrs-and-go-query/50919/2 |
|
One of my overlays broke because of a mistake I did but I think we can avoid that. Fix in #339042 |
|
@doronbehar I proposed |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/is-it-possible-to-override-cargosha256-in-buildrustpackage/4393/22 |
Description of changes
The Go package builder
buildGoModuleis refactored to adopt the overlay-stylestdenv.mkDerivation(#119942) and to fix overriding. One can now overridevendorHashusingoverrideAttrs. This addresses #86349 (comment)The
goModulesandvendorHashattributes are moved out ofpassthruas they are already exposed asstdenv.mkDerivationattributes. They can still be accessed aspet.vendorHash, but no longerpet.passthru.vendorHash. The builder now only addsgotopassthru.To address the issue of
vendorHash = nullthroughoverrideAttrsmay break the overriding ofgoModules, this PR also provides an overridablepassthru.overrideModAttrsthat will be applied togoModuleswhenvendorHashis notnull.Closes #86349
Comparison to similar PRs:
In this PR, the diff of
pkgs/build-support/go/module.nixis shorter than #171586.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)