As part of https://github.com/pantsbuild/pants/pull/12955, we are trying to figure out how to allow configuring Pants to download a tool automatically while also allowing configuring use of a system-installed tool. One idea that I had is to make tool configuration into a target type. Any thoughts/comments on that approach? 1. This is what Bazel does with its notion of a “toolchain”: https://docs.bazel.build/versions/main/toolchains.html 2. A benefit of having tools be targets is that they can become (inferred) dependencies of code-related targets. For example, the Go SDK could be a target type and made a dependency of

go_mod

targets. This would allow multiple Go modules in a repository to use different Go SDK versions (or options to those SDKs) by specifying a different “go_sdk” target.

The alternative is "named resolves" style, where you define a couple valid configs in a subsystem then have a field in the target to tell or which to use

Another advantage of them being targets is that you could potentially build the tool from code in the repo!

Another advantage of them being targets is that you could potentially build the tool from code in the repo!

Which Bazel actually supports for tools

there was some discussion of this recently here too: https://github.com/pantsbuild/pants/pull/13057#discussion_r719967332

> Another advantage of them being targets is that you could potentially build the tool from code in the repo!

Which Bazel actually supports for tools

I will mention... Very badly, currently. There's an issue where you kind of want some mutual recursion going on in how these tools are resolved, and Bazel doesn't offer any of that. So say you need to find a JDK and a Scala toolchain which are compatible (or say you need to do some Scala compilation in order to bootstrap your Java toolchain) - there's no nice way to do that in Bazel right now. One of the toolchains just needs to be picked/configured/built first, and then the other, and they can't factor into each other's configuration. And this multiplies in complexity when you consider that some of these things may be being built on different platforms (e.g. local vs remote). It's a hard problem, and I don't entirely blame Bazel for how it approaches it, but... It's a messy can of worms.

It's at least a reflection of the inherent circular dependency in existing bootstrapping problems

I'm a little out of my depth in this conversation, but is this going to be written for Terraform in a way that supports tfenv/asdf? Similar to how selecting the python interpreter can work? I was hoping that would be an easy way for people actually using Terraform vs folks just trying to lint the repo to use the "same" Terraform version, even if pants has to download (or build?) it. Another option is that Terraform's hcl has a

terraform

config block where a version constraint string can be passed. I'm not sure how deep you all want to parse hcl...