I'm struggling with some non-optimal behaviour with a Python/Go monorepo built using Pants and wondering whether I've set things up poorly. I've noticed that many tasks I ask Pants to perform will do a lot of Go "stuff" which might be entirely unnecessary. For example, if I

pants test path/to/some/file.py

, I see Pants compile a whole bunch of Go modules which do happen to be dependencies of my Go code but can't reasonably be thought to be needed for Pants to run

pytest

for me 🙂 Is this an artefact of Go support being quite early? Something I've set up poorly / something I could look at from my side? Something else? I'm on 2.16.0rc0 right now.

Probably because the Pants Go backend, among other actions, uses the engie's "target generation" feature to generate targets for third-party dependencies and builds code to perform import analysis for first-party dependencies for dependency inference. And the Pants core rules eagerly want to see all targets, which means Pants eagerly analyzes Go code even if the current operation is only for Python.

you’re right, and that’s an important insight. added a comment to https://github.com/pantsbuild/pants/issues/14720#issuecomment-1574152124 on this topic… it should be possible to skip target generation for unrelated languages in cases like this.

Could the go dep inference switch to running via tree-sitter in rust, rather than needing to build/run go code? If it did, would that be enough to resolve this specific issue? (Admittedly not helping the bigger picture)

I'd rather we first find a way to not run target generation when not necessary. The Go analysis code is written in Go and uses parts of Bazel rules_go and the Go stdlib. I would rather avoid replicating that code in Rust.