RFC: Gophers! I'm working on letting Pants instal...
# general
g
RFC: Gophers! I'm working on letting Pants install go toolchains automatically, without a host toolchain available. As part of this, I'm debating whether we should keep the ability to use a native toolchain. With the multi-version support in recent Go and the ability to select a toolchain from Pants I'd prefer to only support a Pants-provided compiler, as it simplifies the code, works better with remote execution, and so on. So if you use
go
through Pants, I'd love to hear your thoughts on this, and how it'd affect you. Would a Pants-provided toolchain work fine for your use-cases? Do you feel like you want a host-provided toolchain still, and if so why?
In practice, this would probably look something like
Copy code
[go-toolchain]
version = "1.21.1"
in
pants.toml
, and from there compilation will continue as before. Some tools might still be needed from the host, this only affects what you'd normally get from the
go
installer.
l
That would work for us, especially because of the remote execution. It also simplifies the developer and CI machines setup. One thing to mention is the performance. At the moment, building Go through Pants takes longer than using direct Go tools so I am aware that some of my colleagues are just skipping the Pants part.
g
That sounds great! Regarding performance that's also something being looked at, through other efforts. Would you say it's a tiny bit slow everywhere, or do you have any workflows or specific cases that stand out as slower than others?
l
I believe the build step (or package in Pants terminology) is one. With "naked" Go tooling it takes seconds, with Pants much longer (and it impacts memory usage massively). This is not to complain, I am aware of all the efforts around Golang šŸ˜‰ I can dig into more details as I don't work on Go at the moment šŸ˜ž
p
I just started using pants with a new go project. Will pants install the toolchain under
~/go
as is standard? I would like goland to use the same version that pants uses.
g
No, in the same way Pants doesn't set up a system python when you use pyenv. But we could conceivably set up something like a tool export.
p
Slightly off-topic analogs in other ecosystems: With rust, I don’t like rustup as I’ve had some issues compiling when I don’t use the system rust on my gentoo box which has a few patches to make rust support the paths Gentoo uses. I doubt I’ll run into the same issue with go (as I use whatever goland installs, not the system provided golang), but I’m wary of tools that manage their own toolchain as I’ve been burned many times by that. I also don’t like using pyenv, as I have the flexibility to install as many system pythons as I want on Gentoo (a source based linux distro). Letting pyenv compile python feels so wasteful when I’ve already compiled it for use system-wide. I do have 1 python interpreter (python 3.4) installed via pyenv because it is so old, system compilation was too much of a pain. Eventually I want to see a plugin that allows me to ā€œprovideā€ python within pants that lets me query the package management system to get pre-compiled packages (portage on gentoo, macports on mac, dnf on Rocky, apt-get on Ubuntu…).
A tool export would be interesting. Making it possible for the IDE to use a go interpreter similar to how pycharm can use a venv exported by pants. I like that idea, and it would satisfy me as far as go is concerned.