Hacker News Reader

Comment by yobert | Hacker News Reader

I think the part they take issue with that might surprise you is if you decide to start using a dependency, and that dependency declares in it's go.mod file (not yours) that it needs a newer version than yours, and that triggers a download and toolchain swap.

I think it's... Iffy. I'd prefer it to fail and for it to be up to me to upgrade, personally.

View on HN

I think that's only what happens for binary (tool) dependencies that are built on their own, though. For library dependencies that you're only building against, their "toolchain" directive would be ignored, because they're not the main module (https://go.dev/doc/toolchain).

OK, if I understand correctly:

I might have a git repo, and nowhere in it does anything say "go1.2x"

My go.mod might say go1.26

But one of the dependencies, in it's source (not anywhere to be found in my source), says go1. 29

So when you build my source, it will build with go1.29

If that's the case, then yes, I'm appalled, AND this article did a terrible job of informing me of the situation

Your go.mod would be considered untidy

> A module’s go line must declare a version greater than or equal to the go version declared by each of the modules listed in require statements.

Idk, I just looked at the go.mod docs (I assume go.mod is the current standard but I really can't say for certain, the go ecosystem is more of a cluster than python, imo): https://go.dev/ref/mod#go-mod-file-go

> The go directive sets the minimum version of Go required to use this module. Before Go 1.21, the directive was advisory only; now it is a mandatory requirement: Go toolchains refuse to use modules declaring newer Go versions.

Seems like a non-issue. I'm still unclear what TFA is saying

That's what GOTOOLCHAIN=local means

Reply on news.ycombinator.com