Ron said:
> one of the things I've gotten to like with Go is not having to build
> new toolchains:
> ...
> It needed the newer version, so it downloaded it for me.
I really hate that. Let me count the ways:
1. It's my computer, what's installed on it should be my choice. One
of the great peace-of-mind features of Plan 9 is that it doesn't
download and update things behind your back.
2. I don't live in the brave new world of unbounded disk space. "Toolchain"
in go doesn't just mean compiler+assembler+linker, it also includes the
whole std and cmd libraries. Download 270+ MB of go source into somewhere
mysterious and build it all into 100+ MB of extra binaries in $home/lib/cache
just so I can try compiling something with a go.mod mentioning a specific
toolchain version? No thanks.
3. If I manage to ferret out where the toolchain has been downloaded to and
try to delete it, surprise!
cpu% rm -r $home/go/pkg/mod/golang.org/[email protected]
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/CONTRIBUTING.md:
permission denied
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/LICENSE:
permission denied
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/PATENTS:
permission denied
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/README.md:
permission denied
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/SECURITY.md:
permission denied
rm:
/usr/miller/go/pkg/mod/golang.org/[email protected]/VERSION:
permission denied
... etc etc ad nauseam
Yes, permissions were set to 0440 to stop me from deleting files which I own.
4. Where exactly are the toolchains downloaded from? The answer is $GOPROXY.
This defaults to https://proxy.golang.org unless the default is different
in the toolchain which just downloaded itself. Do you trust the proxy? Hmmm,
two weeks ago there was a security point release of go1.26.3 to fix (some of?)
the things a malicious module proxy can do. In particular, [quoting from the
announcement in golang-dev]:
"A malicious module proxy can bypass checksum database validation for this
downloaded toolchain. Since this vulnerability affects the security of
toolchain downloads, setting GOTOOLCHAIN to a fixed version is not
sufficient.
You must upgrade your base Go toolchain."
5. The algorithm to determine which toolchain to download seems
counterintuitive.
Suppose I try to build something which requires at least go1.26 (without
specifying
a point release:
cpu% cat go.mod
module hamnavoe.com/main
go 1.26
cpu% go build t.go
go: downloading go1.26.0 (plan9/386)
...
Why does it download 1.26.0 when security fixed 1.26.3 is available?
6. Building from source is not the only thing to trigger a toolchain download.
Suppose I want to find out the exact point release for a particular toolchain:
cpu% /sys/lib/go1.25/bin/go version
go: downloading go1.26.0 (plan9/386)
...
WT actual F?
Oh yes, I forgot to say the magic word:
cpu% GOTOOLCHAIN=local /sys/lib/go1.25/bin/go version
go version go1.25.0 plan9/386
7. You might think I could just set GOTOOLCHAIN=local to get the old
deterministic
behaviour again (just use the go binary I bound into /bin, ok?). Sadly not:
cpu% GOTOOLCHAIN=local
cpu% go build t.go
go: go.mod requires go >= 1.26 (running go 1.25.0; GOTOOLCHAIN=local)
What do I have to do to invoke the actual compiler version I asked for?
cpu% rm go.mod # hammers on keyboard and swears
cpu% ls -l go.mod $home/go.mod $home/foo/go.mod
ls: go.mod: 'go.mod' file does not exist
ls: /usr/miller/go.mod: '/usr/miller/go.mod' does not exist
ls: /usr/miller/foo/go.mod: '/usr/miller/foo/go.mod' does not exist
cpu% GOTOOLCHAIN=local /sys/lib/go1.25/bin/go build $home/foo/t.go
go: ../go.mod requires go >= 1.26 (running go 1.25.0; GOTOOLCHAIN=local)
cpu% GOTOOLCHAIN=go1.25 /sys/lib/go1.25/bin/go build $home/foo/t.go
go: downloading go1.25 (plan9/386)
go: invalid toolchain: go1.25 is a language version but not a toolchain
version (go1.25.x)
cpu% GOTOOLCHAIN=go1.25.0 /sys/lib/go1.25/bin/go build $home/foo/t.go
go: ../go.mod requires go >= 1.26 (running go 1.25.0; GOTOOLCHAIN=go1.25.0)
I think I can safely say that with every compiler I've used in the past 54
years,
I could apply a specific compiler version to a specific source file and it
would do as I asked. With go, not so much, if there happens to be a go.mod file
in any ancestor directory of the source file ... or in any ancestor of the
directory the shell happens to be running in, even though it has no relation
to the source file.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T2da0aea1ca5286e8-Mb035a84076f8a2239e9cd697
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
