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

Jump to bottom

cmd/go: error out of more commands used by module authors if go.mod's Go version is newer #50468

Closed
mvdan opened this issue Jan 6, 2022 · 3 comments
Closed

cmd/go: error out of more commands used by module authors if go.mod's Go version is newer #50468

mvdan opened this issue Jan 6, 2022 · 3 comments
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.21

Comments

@mvdan
Copy link
Member

mvdan commented Jan 6, 2022

#46142 is a great change. It would have saved some head scratching for a coworker of mine, who was running go mod tidy on 1.16.x on a module that declared go 1.17. This version mismatch was causing problems, such as unintentionally removing some require lines.

I reckon we should throw this error for any command that relates to authoring a module and not just using it. Of course, only when run inside a module that has such a version mismatch. Off the top of my head:

  • go get, as nowadays it's only used for changing the module requirements.
  • go work, given how similar it is to go mod. Perhaps it should compare with the go 1.N line in the go.work file?
  • go fix and go generate, as they can only be useful to an author, given how they modify source files
  • Any other go mod command, not just go mod tidy. For instance, go mod edit or go mod vendor both feel potentially broken on a version of Go that's too old.
@mvdan
Copy link
Member Author

mvdan commented Jan 6, 2022

One may argue that there's no harm in some of these, like go fix or go generate, but I also think we should consistently push authors towards using a Go version that's recent enough to be compatible with authoring a module.

@bcmills
Copy link
Contributor

bcmills commented Jan 6, 2022

I think go generate and go fix are probably ok — if the generator program runs successfully on the older version it should produce the same output, and go fix on a newer version shouldn't actively undo transformations applied by go fix on an older version (or vice-versa).

But I agree that go get and go work should probably error out if they don't know how to interpret the main module's (or the workfile's) go version.

@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 7, 2022
@thepudds thepudds mentioned this issue Feb 3, 2022
Closed
@bcmills bcmills added this to the Backlog milestone Feb 3, 2022
@bcmills
Copy link
Contributor

bcmills commented Oct 31, 2023 •
edited

This should have been fixed by the changes for #60421. At this point, any go command in a module or workspace that declares go 1.21 or higher should either automatically upgrade the toolchain or fail explicitly.

@bcmills bcmills closed this as completed Oct 31, 2023
@bcmills bcmills modified the milestones: Backlog, Go1.21 Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
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
Milestone
Go1.21
Development

No branches or pull requests
3 participants
@cagedmantis @mvdan @bcmills