pants for terraform has been quiet and stale for a while: github.com/pantsbuild/pants/issues/21119 be honest, is there any real benefit to using pants to wrap tf other than just a single point of entry CLI (pants)? for straightforward terraform repos (I know, hard to believe) my first reaction is it seems like the added layer would be too confusing for maintainers that aren't both a TF expert + pants expert. Am I missing something obvious?

My off the cuff take, not claiming any authority here: for a repo that's only Terraform, I don't think the benefit clears the overhead. Pants earns its keep when you have multiple languages, shared deps, and fine grained caching/invalidation across a big target graph. Strip that away and you're mostly paying the setup and maintenance cost for a nicer entry point CLI. And the maintainer cost you called out is real. Needing to know both TF and Pants to debug the build is a steep ask for a repo where terraform fmt/validate/plan already gets you most of the way.

thanks Jason, appreciate the honesty! fwiw I'm enjoying Pants so far (still pretty new to it) in python+typescript+shell codebases, but your points are exactly what I was afraid of for this use case.

It's possible that large terraform monorepos could value from it, but I'm not familiar enough with the pants backend for terraform to know what benefits would come from that.

we use it. with shared modules and such, the dependency graph is helpful to detect what is impacted by a change. Of course, you could just reapply everything since terraform is ~mostly idempotent. But I'm not sure we'll stick with it long term. Fortunately, pants is such a thin layer that it's an easy to swap to manually running terraform. You have to solve some of things that pants provides like ensuring that everyone is on the same terraform/linter/etc version, though, another way.

The dependency graph is the specific thing I was thinking when I said a large terraform monorepo because exactly this ^^.

yeah deifnitely

and I'm assuming pants doesn't

-target

apply regularly (brings TF shame) but rather for example let's say the repo has dozens or hundreds of different "apply-able" directories, aka environments, and each one of those sources many dozens of TF modules too.. then pants determines if only ~3 environments changed (or their upstream dependency modules) and therefore only terraform applies those?

@bright-orange-25107 I've not used the terraform backend, but assuming it mimics other source code backends, that would be true.

yeah @bright-orange-25107 that's correct - you need to model each one as a separate terraform_deployment() to get similar functionality. which would be very disruptive if your team is used to a mono-deployment with targeted applies.

oh you see, I don't know the specifics of the terraform backend. Seems like more functionality is built out than I assumed or knew.

yeah @dazzling-pizza-75442 that's what I was thinking of. for terraform specifically, pants' dependency graph isn't an excuse for bad TF repo layout, like putting everything into just 1 or a few deployable environments because that would end up needing to terraform apply against a huge number of resources and defeat the benefits of pants (and just has a large blast radius in general)

Slightly related: In our company we use Pulumi (python) via Pants (using a custom plugin), and I think that makes more sense than terraform because the pulumi code it runs is just normal python code in the same resolve and code tree, and is managed by Pants like all the other python code in the repo. We are quite happy with the arrangement.

As the person who wrote the Terraform backend initially while I was Toolchain, I wrote it as a proof of concept for using Pants to manage something that was not traditional source code. The original backend PR only provided fmt and lint goals. Others extended the backend for actually applying state.

When were using a build tool to manage terraform (please not pants) the main benefit we found from it was the ability to have the build system assemble information and have it stored there instead of in terraform files The build system because the source of truth for a lot of stuff and we also used it to generate some files for TF. For us this was very valuable but YMMV