Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: get -d upgrades version for modules in subfolder #48069

Closed
bep opened this issue Aug 30, 2021 · 7 comments
Closed

cmd/go: get -d upgrades version for modules in subfolder #48069

bep opened this issue Aug 30, 2021 · 7 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@bep
Copy link
Contributor

bep commented Aug 30, 2021

This worked as expected in Go 1.16.7.

 go version && uname -a
go version go1.17 darwin/amd64
Darwin bep-mac16.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64
mkdir mymod
cd mymod
go mod init mymod
go get -d github.com/bep/mod-subs/mod1@v1.0.0
go get -d github.com/bep/mod-subs/mod1
go get: upgraded github.com/bep/mod-subs/mod1 v1.0.0 => v1.1.0
mymod git:(master) ✗ go mod graph
mymod github.com/bep/mod-b@v1.0.0
mymod github.com/bep/mod-subs/mod1@v1.1.0
github.com/bep/mod-subs/mod1@v1.1.0 github.com/bep/mod-b@v1.0.0
github.com/bep/mod-subs/mod1@v1.1.0 github.com/bep/mod-d@v1.0.0

Doing the same with go1.16.7:

...
go mod graph
mymod github.com/bep/mod-subs/mod1@v1.0.0
github.com/bep/mod-subs/mod1@v1.0.0 github.com/bep/mod-b@v1.0.0
github.com/bep/mod-subs/mod1@v1.0.0 github.com/bep/mod-d@v1.0.0
@jayconrod
Copy link
Contributor

Is this explained by https://golang.org/doc/go1.17#graph-pruning? The way the go command manages module graphs changed substantially in 1.17, and since this example starts with a new go 1.17 module, this may be working as intended.

If not, please fill out the issue template and add more detail, especially in "What did you expect to see?".

@jayconrod jayconrod added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 30, 2021
@bep
Copy link
Contributor Author

bep commented Aug 30, 2021

"What did you expect to see?".

  • I expect go get -d some-module to respect the version set in go.mod (as in: the version I already installed). This is a very simple dependency graph, and I can see no reason for an upgrade.
  • This is a direct dependency and I can see no relevance with your "graph pruning" reference.
  • This works as expected when the go get-ed module is living in the repository root.
  • And as I said, this also works as expected in Go 1.16.7.

@jayconrod
Copy link
Contributor

I expect go get -d some-module to respect the version set in go.mod (as in: the version I already installed). This is a very simple dependency graph, and I can see no reason for an upgrade.

go get -d path is equivalent to go get -d path@upgrade. When no version is specified, go get upgrades the packages or modules listed on the command line to the latest available version. So go get -d github.com/bep/mod-subs/mod1 should upgrade to v1.1.0. Both Go 1.16 and 1.17 will do that.

This is a direct dependency and I can see no relevance with your "graph pruning" reference.

Graph pruning means that in 1.17, after the go get commands, your go.mod file looks like this. It includes explicit requirements on all modules needed to build the packages listed by the go get command.

module mymod

go 1.17

require (
	github.com/bep/mod-b v1.0.0 // indirect
	github.com/bep/mod-subs/mod1 v1.1.0 // indirect
)

This affects the output of go mod graph.

This works as expected when the go get-ed module is living in the repository root.

Do you mean when the argument to go get is the main module or a package within the main module? Or do you mean when the argument is another module that's the subject of a replace directive? And by "works as expected" do you mean that it isn't upgraded? Or something else?

@seankhliao
Copy link
Member

I see the same behaviour in 1.16 as 1.17:

main » go1.16.7 mod init test
go: creating new go.mod: module test

main » cat go.mod
module test

go 1.16


main » go1.16.7 get -d github.com/bep/mod-subs/mod1@v1.0.0
go get: added github.com/bep/mod-subs/mod1 v1.0.0

main » cat go.mod
module test

go 1.16

require github.com/bep/mod-subs/mod1 v1.0.0 // indirect


main » go1.16.7 get -d github.com/bep/mod-subs/mod1
go get: upgraded github.com/bep/mod-subs/mod1 v1.0.0 => v1.1.0

main » cat go.mod
module test

go 1.16

require github.com/bep/mod-subs/mod1 v1.1.0 // indirect

@bep
Copy link
Contributor Author

bep commented Aug 30, 2021

OK, I'll close this for now (I repeated the steps above on Go 1.16 and now it behaved differently, which does not make much sense). I will get back to you when I find out what the real issue is

go get -d path is equivalent to go get -d path@upgrade.

That is not even mentioned in go help get. That is the behaviour I would expect from go get -u.

Anyhow, I will get back with a more stable test case.

@bep bep closed this as completed Aug 30, 2021
@seankhliao
Copy link
Member

It is mentioned as the first example:

To add a dependency for a package or upgrade it to its latest version:

go get example.com/pkg

@bep
Copy link
Contributor Author

bep commented Aug 30, 2021

You are all right, I'm sorry. My issue was something completely different.

@golang golang locked and limited conversation to collaborators Aug 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants