https://pantsbuild.org/ logo
#development
Title
# development
f

fast-nail-55400

10/05/2021, 9:06 PM
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.
👍 2
h

hundreds-father-404

10/05/2021, 9:17 PM
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
h

happy-kitchen-89482

10/05/2021, 10:02 PM
Another advantage of them being targets is that you could potentially build the tool from code in the repo!
f

fast-nail-55400

10/05/2021, 10:03 PM
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
And some of this idea overlaps with selecting tools in multi-platform scenarios.
w

witty-crayon-22786

10/05/2021, 10:04 PM
there was some discussion of this recently here too: https://github.com/pantsbuild/pants/pull/13057#discussion_r719967332
a

average-vr-56795

10/05/2021, 11:00 PM
> 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.
👍 3
b

bored-art-40741

10/06/2021, 1:48 AM
It's at least a reflection of the inherent circular dependency in existing bootstrapping problems
👍 1
The reproducible builds folks have been working on this for a while, with an actual DAG that goes back to some tiny formally proven C compiler that bootstraps a regular C compiler and so on
👍 1
In other words, it's not necessarily a problem with the model, it's just that you end up accidentally modeling something insane that we are all mostly ignorant of in everyday development
👍 1
w

worried-salesclerk-37834

10/13/2021, 8:36 PM
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...