Change:
buildGoModule = buildGo116Module; }; <del> victoriametrics = callPackage ../servers/nosql/victoriametrics { }; </del> <ins> victoriametrics = callPackage ../servers/nosql/victoriametrics { buildGoModule = buildGo116Module; }; </ins> virtiofsd = callPackage ../servers/misc/virtiofsd { };

Discussion:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.

I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.