Open rogpeppe opened 1 year ago
bcmills
commented
1 year ago The
go.work.sumfile was updated as a result of runninggo list
What was the actual go list command? In general that can result in loading packages beyond what is required by go mod tidy and go work sync, and in workspace mode we're a bit more tolerant of missing checksums because the user may be combining modules for testing without intending to sync their dependencies.
rogpeppe
commented
1 year ago What was the actual go list command?
Just plain "go list" (I've included the full reproducer above). "go test" also suffices, and probably other commands too.
bcmills
commented
10 months ago Hmm. So, I wouldn't expect go mod tidy to use go.work.sum at all (it uses the single-module view, not the workspace view; compare #50750.
I agree that go work sync should have prevented further changes, though: it writes out the go.mod and go.sum files for each individual module, but perhaps it is missing a call to write out the go.work.sum file for the workspace overall?
(CC @matloob)
jalaziz
commented
8 months ago I've been running into this and I think things are a bit more sinister than just missing entries.
We have a workspace with two modules (A & B) and I see different behavior depending on the order in which I run things. In my case, I have a module A which has missing dependencies in go.mod and module B which has an indirect dependency which should now be marked as direct.
go work syncThis will update add missing dependencies to go.mod and go.sum for module A (and presumably any other module), but it will NOT cleanup or modify go.work.sum and it will not tidy modules that aren't missing dependencies.
go mod tidy in each module followed by go work syncThis is where I see some odd behavior. Depending on the order in which I run go mod tidy, I see different results.
If I run go mod tidy on module B, followed by module A, I see missing dependencies added to module A and module B being tidied (e.g. indirect reference marked as direct).
If I run go mod tidy on module B, followed by module A, I see missing dependencies added to module A. However, module A's dependencies now get upgraded to match the newer versions in module B.
Running go work sync after does nothing in either case.
go work sync followed by go mod tidy in each moduleThis seems to be the most consistent. go work sync adds the missing dependencies to module A. Then running go mod tidy in each module produces a consistent result (the modules are tidied and order doesn't matter).
go mod tidy followed by go list -m allThis is where things get super weird.
If I run go mod tidy on module B, followed by module A, I see missing dependencies added to module A and module B being tidied (e.g. indirect reference marked as direct). Great.
If I then run go list -m all, the go.work.sum file seems to get tidied (some dependencies are removed and others are added)!
If I invert the order in which I run go mod tidy on the modules, go list -m all does not update the go.work.sum file!
go list -m allThis does nothing on its own.
go list -m in any of the scenarios aboveThis also does nothing.
go work sync followed by go mod tidy then go list -m allThis is the same as the third scenario and go.work.sum is not modified.
Given all this, it seems like go work sync followed by go mod tidy produces the most consistent results. However, it's very odd that go work sync does not update/tidy the go.work.sum in scenarios where go list -m all will.
jalaziz
commented
8 months ago Been doing some more testing and ran into a scenario where go list -m all doesn't change the go.work.sum, but go mod download does.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I ran the following testscript script:
What did you expect to see?
A passing test, or at least either
go mod tidyorgo work syncshould have updated thego.work.sumfile.What did you see instead?
The
go.work.sumfile was updated as a result of runninggo list, not either of the two previous commands (go mod tidyandgo work sync).If I go into the
cmd/ocisrvdirectory and rungo mod tidy, itsgo.sumfile does change (but note: this was not because any code or dependencies have changed in that directory), but there's no easy way to rungo mod tidyon all modules in a repository, so it's easy to run into annoying CI failures this way.I think that after running
go work sync, allgo.mod,go.sumandgo.work.sumfiles should be consistent and not change when running other normal go commands likego list.