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

remove spurious "toolchain" from go.mod #819

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cwedgwood
Copy link

Having go.mod specific a exact toolchain is not required and breaks some build systems. The preference is to remove this allow Go to use the appropriate installed tooling.

Resolves: #818

Having go.mod specific a exact toolchain is not required and breaks
some build systems.  The preference is to remove this allow Go to use
the appropriate installed tooling.
@thediveo
Copy link
Collaborator

thediveo commented Jan 15, 2025

With https://go.dev/doc/toolchain as the authoritative documentation on toolchain semantics, all interpretation errors are thus to blame on me.

The toolchain mechanism has been introduced as of Go 1.21(.0). Gomega follows the N, N-1 support policy which at this moment resolves to 1.23.x and 1.22.x. It's debatable whether the toolchain should be 1.22.10, 1.22.0, or maybe 1.21.0 to better allow for some skew. But to my limited understanding we cannot keep a toolchain definition from Gomega's go.mod anymore, more so as our dependencies also now introduce toolchain definitions of their own.

You can always enforce your local toolchain with GOTOOLCHAIN=local, but if it is outside the lower limit of the support range this will fail. Still, you have some control, in particular, the choice of 1.22.x or 1.23.x if I understand the situation correctly.

@cwedgwood
Copy link
Author

With https://go.dev/doc/toolchain as the authoritative documentation on toolchain semantics, all interpretation errors are thus to blame on me.

The toolchain mechanism has been introduced as of Go 1.21(.0). Gomega follows the N, N-1 support policy which at this moment resolves to 1.23.x and 1.22.x. It's debatable whether the toolchain should be 1.22.10, 1.22.0, or maybe 1.21.0 to better allow for some skew. But to my limited understanding we cannot keep a toolchain definition from Gomega's go.mod anymore, more so as our dependencies also now introduce toolchain definitions of their own.

You can always enforce your local toolchain with GOTOOLCHAIN=local, but if it is outside the lower limit of the support range this will fail. Still, you have some control, in particular, the choice of 1.22.x or 1.23.x if I understand the situation correctly.

Thanks, I'm aware of the background to toolchain and how to avoid some issues; but nonetheless it's not needed here and only showed up when it caused a regression in an internal system.

I think the correct and safe thing to do it remove it.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

go.mod contains an explicit toolchain
3 participants