@niallnsec is this new in 1.17? Can you reproduce with 1.16?

CC @bcmills @jayconrod @matloob via https://dev.golang.org/owners

Yes this only seems to happen with go 1.17.

I don't think I made it very clear above (sorry about that), but the two code blocks in the report above show me using go get -u on the same repository sequentially. Running the first go get -u using Go 1.17 updated a single entry and downloaded updated code for two others but did not update go.mod. (Running the command again using 1.17 had no effect). Then I ran the same command using Go 1.16.4 and it proceeded to update all the dependencies as expected.

Go 1.16.4 worked as expected, 1.17 appeared to ignore most of the available updates, even though it had downloaded updated code for two of them.

@niallnsec Thanks for reporting this. It sounds like there might be a bug here, but we need more information to understand what's going on.

• Ideally, do you have a public repo that reproduces this problem? Or can you put together a small example?
• Does go list -m -u all show the updates you expect?
• For modules that are not updated by 1.17, are the packages they contain imported directly from the package in the current directory? Indirectly? By tests?
• What version does the go directive have in go.mod?

I have not got a public repo example at the moment, but will keep looking or try to create a test case that has the same behaviour. In the mean time, to answer your other questions:

Does go list -m -u all show the updates you expect?

Yes, for both go1.16.7 and go1.17 the output of go list -m -u all are identical.

For modules that are not updated by 1.17, are the packages they contain imported directly from the package in the current directory? Indirectly? By tests?

The modules not updated are imported both directly and indirectly.

What version does the go directive have in go.mod?

When I upgraded to go 1.17 I update the go directive to 1.17, then did a go get -u followed by a go mod tidy. Prior to that the directive was go 1.16. I now have two require blocks in my repository as was expected.
So all tests show were done with a go directive of 1.17.

I am using a private company Go proxy in my environment, so I disabled that before running the tests to make sure it wasn't playing a part. I get the same results with it in use or not.

Thanks, that helps cross out a few possible causes, but we'll probably still need a reproducible example to figure out what's going on.

I have created a small demo project here: https://github.com/niallnsec/demo_auth

I took the go.mod and go.sum files from my private module exactly as they were following the initial update to Go 1.17. The only edits done manually on these two files (ever) is to remove references to three other internal projects. Otherwise, the module is still importing all of the same public module as in my previous tests.

Using that repository, when using Go 1.16 go get -u gives me the following:

[0] % go get -u
go get: upgraded github.com/aws/aws-sdk-go v1.40.23 => v1.40.27
go get: upgraded golang.org/x/crypto v0.0.0-20210711020723-a769d52b0f97 => v0.0.0-20210817164053-32db794688a5
go get: upgraded golang.org/x/net v0.0.0-20210805182204-aaa1db679c0d => v0.0.0-20210813160813-60bc85c4be6d
go get: upgraded golang.org/x/sys v0.0.0-20210806184541-e5e7981a1069 => v0.0.0-20210820121016-41cdb8703e55
go get: upgraded golang.org/x/text v0.3.6 => v0.3.7

However, Go 1.17 does not update all of the packages in the same way when I run the command:

[0] % go1.17 get -u
go get: upgraded github.com/aws/aws-sdk-go v1.40.23 => v1.40.27

In this specific case, all of the modules not updated are indirect imports. The three private modules I removed are all direct imports of the original module these files were taken from and they did not update either when using Go 1.17, although one of them was downloaded.

Thanks, that's really helpful. I was able to reproduce this and narrow it down a bit. Working to find the root cause.

It's likely we'll want to backport the fix to 1.17.1.

Change https://golang.org/cl/343879 mentions this issue: cmd/go: ensure 'go get -u' can upgrade pruned (1.17+) modules

@gopherbot Please backport to 1.17. This is a bug in new functionality.

Backport issue(s) opened: #47857 (for 1.17).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

I see the same issue as @niallnsec. Private modules are not updated in go.mod file with go get -u ./... under go 1.17 (though they are downloaded), they do get updated with the same command under go 1.16.7. I also noticed that if I run specifically go get -u <private module name> with go 1.17, it does get updated in the go.mod file. This is a pain, as we often refresh our dependencies using go get -u ./... which used to work flawlessly up to 1.16.7 (and including).
My ugly hack to get around this is the following bash snippet:

go get -u ./...
for priv_mod in $(tail +2 go.mod | awk '/<private repo>/ {if ($1 =="require") print $2; else print $1;}'); do
	go get -u "${priv_mod}"
done
go mod tidy

@tsipo Could you confirm that 1) the main module has go 1.17 in go.mod and 2) the private dependencies that should have been upgraded also have go 1.17 in their go.mod?

If one of those is not true, please open a new issue with enough info to reproduce. It may be a separate bug.

@tsipo Could you confirm that 1) the main module has go 1.17 in go.mod and 2) the private dependencies that should have been upgraded also have go 1.17 in their go.mod?

If one of those is not true, please open a new issue with enough info to reproduce. It may be a separate bug.

@jayconrod Yes, I can confirm these are all 1.17. I first upgraded all of my libraries in their dependency order (some of the private libraries depend on others), then I upgraded all of my "main modules" which depend on these libraries.
This is from the top level folder (all of the modules - libraries and mains - reside under it):

$ grep -r --include "*.mod" 'go 1' . | grep -c 1.17
13
$ grep -r --include "*.mod" 'go 1' . | grep -c 1.16
0

Thanks for confirming. I think https://golang.org/cl/343879 should fix this for you.