Working with release candidates

[cpu...@gmail.com]

I'm preparing our application for go1.24, including using the tools go.mod directive. I was expecting that I should be able to require rc1 as part of the build process. However, adding 

go 1.24rc1

toolchain 1.24rc1

lead to either

unknown block type: tool

invalid toolchain version '1.24rc1': must match format go1.23.0 or default

https://go.dev/doc/modules/gomod-ref does not mention RC versions, while https://go.dev/doc/toolchain does.

Can RC versions be required through go.mod?

Thanks,

Andi

[Alex Bozhenko]

You missed go:

go 1.24rc1

toolchain go1.24rc1

Go toolchain names¶

The standard Go toolchains are named goV 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 which version was used:
go version ./your_binary

https://tip.golang.org/doc/toolchain#config
> If the toolchain line is omitted, the module or workspace is considered to have an implicit toolchain goV line, where V is the Go version from the go line.

So you only need to use 'go 1.24rc1' line.

[cpu...@gmail.com]

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?

[Jeffery Carr]

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 newer version of Go."

Can someone explain how to disable this? I never want to download anything at compile time. I'm also sure there are a huge number of real reasons why that is not acceptable.

Is it acceptable to never publish a "toolchain" option in the go.mod file or is it required? If it's not going to be required, I will just remove it from all of my go.mod files before I publish them.

Thanks in advance,

Jeff

[Brian Candler]

> Can someone explain how to disable this? I never want to download anything at compile time.

go env -w GOTOOLCHAIN=local

[Jeffery Carr]

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 actually put

go env -w GOTOOLCHAIN=local build go.wit.com/apps/helloworld@latest

That is un-ideal. It's amazingly complicated to know when you need a specific toolchain. It almost never happens to anyone to even know when that is possible. I'm a novice here and I know for sure I would never be able to tell at this point. Why is this not the default (GOTOOLCHAIN=local). You have to be really really really smart and knowledgeable to know that you need a specific toolchain. Almost no one ever will every know that is the case.

my 2 cents,

jcarr

--
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/DknrmQ9hi60/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/3d862d72-782b-4331-b20c-4f2f2bb1ff17n%40googlegroups.com.

[Michael Pratt]

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
        golang.org/x/sync v0.10.0 // indirect
        golang.org/x/tools v0.28.0 // indirect
)
```

$ go version  # go binary is 1.23

go: downloading go1.24rc1 (linux/amd64)
go version go1.24rc1 linux/amd64

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/0205f49b-9aca-442f-bedf-9509e87b08d5n%40googlegroups.com.

[Jeffery Carr]

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!

Putting this information in go.mod is "out of scope" in my opinion.

best wishes,

jcarr

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/DknrmQ9hi60/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CALoThU9HYXRYG8seggX%2Bot4%3Dn0vxcaQ2gKOYXzrMn7RH4QEd4g%40mail.gmail.com.

[Jeffery Carr]

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 protocol buffer libraries that can not be compiled without proto-gen-go (and protoc) and a new tool "autogenpb" (which auto generates Marshal() and Sort() functions) that it would be useful to indicate must already be installed.

versions of required binaries are, in my experience, best left to the OS distribution and packaging people.

jcarr

[Dan Kortschak]

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 the
build's dependencies makes this non-achievable.

[tapi...@gmail.com]

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.

[cpu...@gmail.com]

Opened https://github.com/golang/go/issues/70949

[Jeffery Carr]

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" entry autogenerated by 'go mod init' and 'go mod tidy' ?

Or, are we supposed to edit the go.mod file and add these by hand?

Also, even in reproducible builds, it would be helpful to have

tool (

    "autogen"

    "protoc"

)

I have a command "autogenpb" that generates Marshal() and Sort() functions that needs 'protoc" and "protoc-gen-go" There are several versions of protoc-gen-go floating around. I don't yet know which ones work and which ones don't.

I was trying to work with git2go also, and that is different because it would be helpful to have

tool (

    "libgit2" // this is the C library

)

Is this a "go build" thing or a "go install" thing? As in, do you need "stringer" for running your app or to build your app? Maybe instead of "tool" it should be "build" and "install" as those are two separate things.

Many questions I'm afraid. Don't get me wrong by that, I think that this would be really useful, but I'm afraid that in my cases, I simply can not know about the versions of build requirements -- especially versions of autogen related things like protoc. Rather than defining the versions there, it's a lot better idea to use the ones that are already installed by the distribution. Embedded linux distributions for sure. Also, lots of the RiscV boards and whatever is available, it's probably better to use whatever is there -- especially -- if it exists at all.

jcarr