Go Toolchain Management from 1.21.0 onwards

[Stephen Illingworth]

With regards to the new Toolchain Management feature introduced in 1.21.0

Currently, my toolchain management is: download the source; compile; set paths to point to the new version. I like this and it works for me.

Am I correct in thinking that the environment variable, GOTOOLCHAIN=local, will
disable the automatic downloading of new Go toolchains and allow me to continue
with my current system?


I hope this isn't seen as a criticism of new developments. It's not meant to be.
But I don't believe I'm in the target audience for this new feature and want to

continue with my work as I am currently.

Regards

Stephen

[Christoph Berger]

As far as I understand the Toolchains document, Go projects made with Go 1.21 or later can demand a particular toolchain for compiling a module (through the go and toolchain directives). If you disable downloading toolchains as needed, the new behavior of the go and toolchain directives might break your workflow.

What prevents you from using the new toolchains mechanism?

[Stephen Illingworth]

On Wednesday, 16 August 2023 at 08:47:36 UTC+1 Christoph Berger wrote:

Thank you for replying.

 

What prevents you from using the new toolchains mechanism?

Nothing really. I suppose it's just that I don't really understand what it is or what it's for.

The current method of dealing with the toolchain is as straightforward as it can possibly be. For me at least. Automatic downloading just seems unnecessarily complicated but I can accept that other people have different needs.

If GOTOOLCHAIN=local disables the automatic downloading and allows me to continue with my current workflow then I'm happy! The document on the change was extensive but not entirely clear on this point.

Regards

Stephen

[Christoph Berger]

I would assume that GOTOOLCHAIN=local does what you want. 

The doc says,

> When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain.

The author of this proposal in docker-library/golang also assumes that GOTOOLCHAIN=local preserves pre-1.21 behavior. 

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/lu2FbQHWg5A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e2540552-ddfb-4ce4-9db3-a4aa92ca0e95n%40googlegroups.com.

[Stephen Illingworth]

On Wednesday, 16 August 2023 at 10:15:50 UTC+1 Christoph Berger wrote:

I would assume that GOTOOLCHAIN=local does what you want. 

The doc says,

> When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain.

That's the conclusion I came to. I wasn't entirely sure what was meant by "bundled" at first but in this context I think it means the go toolchain that has been manually installed.

 

The author of this proposal in docker-library/golang also assumes that GOTOOLCHAIN=local preserves pre-1.21 behavior.

 I'll take that as confirmation. Thanks