Re: [go-nuts] Re: Working with release candidates

On Friday, December 20, 2024 at 5:49:04 PM UTC-6 Dan Kortschak wrote: Almost certainly not. The point of module version specification is to allow reproducible builds. Leaving this up to things outside the build's dependencies makes this non-achievable. Well, we agree then, but is this "tool

Re: [go-nuts] Re: Working with release candidates

Opened https://github.com/golang/go/issues/70949 On Friday, December 20, 2024 at 10:57:50 PM UTC+1 Michael Pratt wrote: > Could you file an issue about this with reproduction steps? My attempt to > reproduce this works fine. > > go.mod > > ``` > module example.com > > go 1.24rc1 > > tool ( >

Re: [go-nuts] Re: Working with release candidates

If you want to know clearly which toolchain version you are using, you can try GoTV (https://go101.org/apps-and-libs/gotv.html). I have used it for two years almost without touching the `go` command directly. On Saturday, December 21, 2024 at 6:07:35 AM UTC+8 Jeffery Carr wrote: > Wow. This syn

Re: [go-nuts] Re: Working with release candidates

On Fri, 2024-12-20 at 16:13 -0600, Jeffery Carr wrote: > versions of required binaries are, in my experience, best left to the > OS distribution and packaging people. Almost certainly not. The point of module version specification is to allow reproducible builds. Leaving this up to things outside

Re: [go-nuts] Re: Working with release candidates

tool ( golang.org/x/tools/cmd/stringer golang.org/x/tools/cmd/toolstash ) Also, I would think you don't want to specify paths here ( stringer toolstash ) would be sufficient. I have a particular use for this feature you are talking about because I have a number of

Re: [go-nuts] Re: Working with release candidates

Wow. This syntax is amazing! This would be really helpful. However, that is not what I was talking about. I see go 1.22 toolchain go1.23.4 The above syntax is much worse than what you posted below. In either case, can you please put this in a new file "go.tool" perhaps? That would be fantastic

Re: [go-nuts] Re: Working with release candidates

Could you file an issue about this with reproduction steps? My attempt to reproduce this works fine. go.mod ``` module example.com go 1.24rc1 tool ( golang.org/x/tools/cmd/stringer golang.org/x/tools/cmd/toolstash ) require ( golang.org/x/mod v0.22.0 // indirect

Re: [go-nuts] Re: Working with release candidates

OK, thank you! I will say I don't understand the thought process or improvement this is adding. I guess I have to change my docs? This seems not ideal. For the purposes of explaining to new users how to do things: go build go.wit.com/apps/helloworld@latest was pretty simple. Now I have to actua

[go-nuts] Re: Working with release candidates

> Can someone explain how to disable this? I never want to download anything at compile time. go env -w GOTOOLCHAIN=local On Friday, 20 December 2024 at 15:07:43 UTC Jeffery Carr wrote: > I also have noticed this new 'toolchain' option. I'm a bit confused about > how it works. > > "This automa

[go-nuts] Re: Working with release candidates

I also have noticed this new 'toolchain' option. I'm a bit confused about how it works. "This automatic toolchain switching can be disabled, but in that case, for more precise forwards compatibility, the go command will refuse to run in a main module or workspace in which the go line requires a

[go-nuts] Re: Working with release candidates

I already did- that's the first error message: go: errors parsing go.mod: go.mod:206: unknown block type: tool It seems that the forward compatibility does not work when the go.mod contains new sections as it fails to parse _before_ the actual Go version selection happens? On Thursday, Decembe

[go-nuts] Re: Working with release candidates

You missed go: go 1.24rc1 toolchain go1.24rc1 Go toolchain names¶ The standard Go toolchains are named go*V* where *V* is a Go version denoting a beta release, release candidate, or release. For example, go1.21rc1 and... Once you build, you can verify whic