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: print information about version changes #33284

Closed
rogpeppe opened this issue Jul 25, 2019 · 8 comments
Closed

cmd/go: print information about version changes #33284

rogpeppe opened this issue Jul 25, 2019 · 8 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@rogpeppe
Copy link
Contributor

Currently, the go command is quite chatty when it downloads and extracts module data, but it doesn't print the information that I really want to see - how resolved versions have changed.

For example, if I run go get $module, it may upgrade the version of the module, but it doesn't tell me what version it ended up with, or that other dependencies have changed version as a result.
Running go get $module@$version can downgrade dependencies too, which is silent and might break expectations of available features.

It would be great if the go command could show some information whenever the resolved module version has changed.

@bcmills @jayconrod

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 25, 2019
@bcmills bcmills added this to the Go1.14 milestone Jul 25, 2019
@bcmills
Copy link
Contributor

bcmills commented Jul 25, 2019

We should do this in conjunction with the fix for #26152. We can prune down the fetch-spam for modules already in the build list, and add logging for changes to that list.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/204777 mentions this issue: cmd/go: adjust module-related logging

gopherbot pushed a commit that referenced this issue Nov 1, 2019
Suppress “finding” messages unless they are unusually slow, and
“extracting” messages always (they almost always occur conjunction
with “downloading”, which is already logged).

Log “found” messages for module dependencies added to satisfy missing
import paths.

Log top-level version changes in 'go get' when the selected version
is not identical to the version requested on the command line.

Updates #26152
Updates #33284

Change-Id: I4d0de60fab58d7cc7df8a2aff05c8b5b2220e626
Reviewed-on: https://go-review.googlesource.com/c/go/+/204777
Run-TryBot: Bryan C. Mills <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Jay Conrod <[email protected]>
@bcmills
Copy link
Contributor

bcmills commented Nov 5, 2019

@rogpeppe, I think this is resolved. Once the tree is a bit less unstable, please try out the new log statements and let us know if we've missed anything.

@bcmills bcmills closed this as completed Nov 5, 2019
@bcmills
Copy link
Contributor

bcmills commented Dec 19, 2019

Hmm, there is one more source of version changes that we should probably log.

If the go.mod file specifies some version explicitly, and we are forced to upgrade that version due to a requirement found in some transitive dependency already present in the go.mod file, we should give a log line indicating the upgraded version and the transitive dependency that forces it.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/219437 mentions this issue: cmd/go: print a "found" line for each package found instead of each module added

gopherbot pushed a commit that referenced this issue Feb 21, 2020
…odule added

We currently print a "go: finding" line for each missing package
during import resolution. However, we are only printing a "go: found"
line for each module: if a given module provides multiple packages, we
don't indicate the module that we found for the second and later
packages.

Before this change:

	$ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07
	go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1
	go: finding module for package golang.org/x/net/html
	go: finding module for package golang.org/x/net/html/atom
	go: downloading golang.org/x/net v0.0.0-20200202094626-16171245cfb2
	go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2

After:

	$ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07
	go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1
	go: finding module for package golang.org/x/net/html/atom
	go: finding module for package golang.org/x/net/html
	go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2
	go: found golang.org/x/net/html/atom in golang.org/x/net v0.0.0-20200202094626-16171245cfb2

Updates #26152
Updates #33284

Change-Id: I221548749e36bfd6a79efe5edc3645dc5319fd6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/219437
Run-TryBot: Bryan C. Mills <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Jay Conrod <[email protected]>
Reviewed-by: Michael Matloob <[email protected]>
@bcmills
Copy link
Contributor

bcmills commented Mar 9, 2020

#37764 has another case: when the user asks go get to downgrade an explicit dependency, we should log other dependencies that were downgraded or removed as a side-effect.

@jayconrod
Copy link
Contributor

cc @matloob

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/269018 mentions this issue: cmd/go: report changes and resolved versions in 'go get'

@golang golang locked and limited conversation to collaborators Nov 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants