wishlist: aliases in PATH that satisfy GOTOOLCHAIN=path #573
Description
The GOTOOLCHAIN documentation has several references to PATH-related behavior that would be potentially reasonable/interesting for us to do something meaningful with:
When
GOTOOLCHAINis set to<name>(for example,GOTOOLCHAIN=go1.21.0), thegocommand always runs that specific Go toolchain. If a binary with that name is found in the system PATH, thegocommand uses it.
To run a toolchain other than the bundled Go toolchain, the
gocommand searches the process's executable path ($PATHon Unix and Plan 9,%PATH%on Windows) for a program with the given name (for example,go1.21.3) and runs that program.
For the
pathform, thegocommand scans the PATH for any executables named for valid toolchains and uses a list of all the toolchains it finds. Using that list of toolchains, thegocommand identifies up to three candidates:
- the latest release candidate of an unreleased Go language version (1.N₃rcR₃),
- the latest patch release of the most recently released Go language version (1.N₂.P₂), and
- the latest patch release of the previous Go language version (1.N₁.P₁).
These are the supported Go releases according to Go's release policy. Consistent with minimal version selection, the
gocommand then conservatively uses the candidate with the minimum (oldest) version that satisfies the new requirement.
Part of me thinks we should put aliases (go1.X.Y + go1.X) in /usr/local/go/bin, but /usr/local/go is otherwise a completely pristine copy of upstream's original artifacts, so that feels slightly wrong and perhaps they belong in /usr/local/bin instead?
However, my main thought for the actual use case for these aliases is folks doing RUN --mount=... to mount several Go versions and use them explicitly with an appropriate GOTOOLCHAIN value (such as path) and $PATH, so perhaps the usability should override the pedantry?
It's also very possible I'm overthinking the whole thing and none of this matters and we should do nothing ("Enjoy Arby's"). 🤷