This comment about an extra resolve in the pants repo got me thinking about some of the scripts included in pants. Example scripts: the helm backend's k8s_parser and post_render scripts; the terraform backend's hcl2_parser script; the python.frameworks.django backend's 2 scripts. Today, the scripts are either treated as python in the main resolve or they are treated as resources. If the script is in the main resolve, and it has dependencies, then we end up working around mypy (skipping it or just ignoring the imports) because the deps are in a tool lockfile and are not actually part of the main resolve. The django backend's scripts do not have any deps, but it treats the scripts as resources effectively skipping all of the python fmt/lint/check tools. If we had a separate resolve for each of our tools (or maybe just for the tools that have pants-provided python scripts), then we could let mypy and other lint/fmt/check tools actually help during development. The resolve could be configured to use the lockfile generated for the tool. How awful would it be to add resolves for these scripts in the pants repo?

Or, conversely, not use tool lockfiles in those (or even all?) cases, and resolve tools from the default resolve?

Would that lead to an explosion in deps needed by pants, and an increase in the likelihood of dep conflicts?

Probably not an explosion, maybe a light firework?

True. We don't have very many of these scripts, so including the deps in the default resolve would probably be ok. The Dockerfile parser was one of the scripts with deps (and a comment suggests that was problematic because some deps didn't provide binary wheels for all platforms), but it's moving to rust. The k8s parser has quite the tree of dependencies in its lockfile, so maybe it could move to the rust side as well, avoiding the libs for communication with k8s. Another likely conflict is black, which the k8s parser depends on via hikaru -> hikaru-codegen. The hcl2_parser, on the other hand, does not have many deps and is unlikely to conflict with our other requirements. The elfdeps script I'm working on now has only pure-python deps, so it would be simple to include them in the default resolve. If we do include a script's deps in the pants default resolve, skipping the creation of the tool lockfile, then that script could run from the pants venv. Or at least that would work locally. But that might not be compatible with running the scripts with remote execution or in a remote environment. Hmm,