remove spurious "toolchain" from go.mod

[cwedgwood]

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

[thediveo]

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]

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!

[blgm]

I think we are moving into a world where toolchain will be standard in go.mod files, but as it's not adding a lot of value here, and it's breaking someone, I'm happy to remove it for now. Though I would expect it to get added back at some point in the future, as the Go tooling sometimes adds it, and it would not be wrong to merge a change that added it.