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
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
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
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
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
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
> 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
It is not slow - but it will be if you don’t use it properly or set the
database up properly.
> On Dec 20, 2024, at 1:19 AM, Kerem Üllenoğlu wrote:
>
> Hey,
>
> I keep hearing ORMs - especially GORM - is slow. But I have never felted like
> it was slow and used in a couple of projects now. I
It appears this issue was previously
reported: https://github.com/golang/go/issues/53532
On Monday, May 13, 2024 at 1:03:22 PM UTC-4 Adam Kaplan wrote:
> I forgot to add one more detail - the go-toolset image defaults to running
> as user "default" (UID 1001).
>
> Adding `USER root` right after
Hey,
I keep hearing ORMs - especially GORM - is slow. But I have never felted
like it was slow and used in a couple of projects now. Is there a good
article you recommend reading about ORMs in Go - especially GORM - being
slow?
Sorry, my reply is not actually an answer to the original questio
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
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
12 matches
Mail list logo
