cmd/go: never remove the toolchain directive when tidying

[maxbrunet]

When the go and toolchain directives are equal, go mod tidy removes the toolchain directive, which in my opinion, "removes the intent" of managing the toolchain version with the go.mod file.

When that happens, tools like dependency update automation (e.g. Dependabot, Renovate) will stop updating the Go version of the project (since the go directive is the minimal supported version, it is not usually desirable to update with the same frequency). And these tools will not add it back since they cannot tell whatever the user wishes to use toolchain, the "intent" has been removed.

The go directive often gets bump by go mod tidy when a dependency requires it, which happens fairly often.

The current behavior adds extra work for the user to keep an eye on the presence of the toolchain directive in their go.mod file, to add it back when there is a new release. Possibly allowing CVEs to accumulate if they do not notice or forget.

Basically, when a user has opted into using toolchain, they should never be opted out by go mod tidy.

Would that sound like reasonable change for go mod tidy?

[gabyhelp]

Related Issues

• go mod tidy removes the toolchain directive #64039 (closed)
• cmd/go: compile error for "toolchain default" in go.mod, removed by mod tidy #73127
• cmd/go: toolchain directive in go.mod being updated unnecessarily #65847 (closed)
• cmd/go: go get -u && go mod tidy behaves differently starting with Go 1.21.0, leading to unknown directive toolchain errors #62409 (closed)
• proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive #69956 (closed)
• cmd/go: error out of 'go mod tidy' if the go.mod file specifies a newer-than-supported Go version #46142 (closed)

Related Code Changes

• cmd/go: adjust conditions in which toolchain lines are written
• cmd/go: only add a 'go' directive on 'go mod tidy' or when a conversion occurs
• cmd/go: upgrade toolchain to 1.24.0 if go.mod declares a tool

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mrkfrmn]

cc @golang/command-line

[matloob]

Hi, I'd like to understand the issue better. I would think that most users would prefer for a toolchain directive to disappear if it's no longer necessary. Would it be possible to add a feature on the automation side to configure it to keep the toolchain directive on the latest released version?

[maxbrunet]

Hi, thank you for looking into this

Would it be possible to add a feature on the automation side to configure it to keep the toolchain directive on the latest released version?

The automation cannot "keep" the directive, they often run go mod tidy as a final step, which removes it, and if they don't, users often have a CI check for go mod tidy that would fail. And the automation cannot decide to add the directive when missing (many users do not want it).

I believe it would make sense for go.mod to show the complete intentions of the user, rather than requiring more configuration options from the automation, that would require more knowledge and cognitive load from the user

if it's no longer necessary

No longer necessary is a very temporary state. For users keeping their dependencies up-to-date, it is necessary most of the time. Another minor issue I can think of, is it makes harder to Git blame toolchain version changes.

I could argue that go and toolchain carry two different semantic meanings and should not be considered equal, the former is VERSION >= value and later VERSION == value. While it is probably fine to fallback to go, I think being able to indicate explicit usage of the feature is better than relying on an implicit behavior, even temporarily

[seankhliao]

For the tooling I've seen, they primarily read from a single canonical source to get the toolchain version, so you don't need to specify it in a bunch of places like a dockerfile, CI config, etc.
Here the canonical source would be the toolchain directive.

Having to keep the module in an untidy state can be quite difficult, as the mod tidy is almost always necessary after a go get, and ci often checks no changes.