Hi all! I wondered if toolchain management has been discussed already somewhere. I'm coming at Pants from an existing monorepo which is built using Please, but interested in evaluating Pants as a potential replacement based on its healthier-seeming community and my hopes of a more mature / better documented tool (not that I don't like Please, just that it can be a bit of a trawl to figure out what's going on when it breaks...) One thing we have in our existing Please repo is a good set of rules for managing both Python and Go toolchains, which results in a high degree of hermeticity since everything right down to the language runtime is reproducibly managed by the build tool. I'm aware that Pants uses lockfiles for tools in Python, but not aware of what the (planned) hermeticity mechanisms are for Go, and both are important to us since we're a mixed-language repo. Really my questions here I think are -- what are people's experience with Pants' support for hermetic builds in the absence of toolchain management; are the lockfiles good enough? What does Pants plan for Go support? Is there a philosophical decision not to manage toolchains using the build tool, and if so what are the arguments for / against? Side-note: Please suffers similar Googlability problems to Pants 🙂

@fast-nail-55400 has contributed most of the Go support, so is the best qualified person to tell you about that. :⁠-⁠)

Thanks for the quick responses! And yes I'd found Toolchain's site by googling for this same problem!

Hi! and welcome @nice-park-16693 👋 you’ll also be happy to learn that the upcoming 2.16.0a0 release will include support for providing a managed Python also for user code https://github.com/pantsbuild/pants/pull/18352 ! 😄 provided by @bitter-ability-32190 🙌

Super cool, thanks for the context @curved-television-6568!

If you want to test it out, let me know! Id love for it to see some air time before the "big release"

@nice-park-16693: What did you want to know specifically about the Go support?

@fast-nail-55400 was that before or after we fixed the same problem in Java-land?

well before the "immutable input" work on

Process

and the newer work superseding immutable inputs to symlink inputs instead

With that in mind: there’s a fairly clear path forward on how to manage the go SDK in a way that is Pants-efficient, which we can probably help someone towards implementing. It’s just not a priority for us to do the heavy lifting ourselves

Yeah we just got this for Python. Opt-in "Pants-provides-it" with the default of "Pants goes looking"

With that in mind: there’s a fairly clear path forward on how to manage the go SDK in a way that is Pants-efficient, which we can probably help someone towards implementing. It’s just not a priority for us to do the heavy lifting ourselves

I have done some initial thinking here. I wanted the Go backend to just have an equivalent to what

pyenv

,

coursier

, and

asdf

do and download and install the Go SDK into a Pants-managed directory.

Do you mean doing what

coursier

does inside pants, when it’s used elsewhere?

I mean doing something similar to what

coursier

does in downloading JDKs but managed from within the Pants rules and not via an external utility as

coursier

is

ah sure

What did you want to know specifically about the Go support?

What interests me here really is what the future might hold for Go toolchain management by Pants. It seems like this might be the answer, which seems like it gives parity with what Please currently does:

I wanted the Go backend to just have an equivalent to what

pyenv

,

coursier

, and

asdf

do and download and install the Go SDK into a Pants-managed directory.

Correct me if I'm misinterpreting what you've said, but otherwise this seems promising and thanks for the responses!