If we have python dependencies that are used exclusively within Pants, those shouldn’t be in the “3rd party/python/requirements.txt”, correct? For example, if we use a dep that’s only used in build-support, should that have a separate resolve? And I guess, moreover, for us, what’s the use case in having 6 resolves? My hope/guess/assumption would be that we would have 2. “Internal” and “External” basically?

I'm confused. Isn't

3rdparty/python/requirements.txt

aka

python-default

, aka the one used by and bundled with Pants itself?

At least partially

Only the actual deps of code distributed as pants end up in wheel metadata and packaged in the pex thanks to pants dependency graph. 🙂 Some of the build-support tooling has to import code from pants, so their deps have to be in the python-default resolve as well. And I'm working on extending a backend in pants where I need to distribute some scripts with pants that have some 3rd party dependencies. The unit tests for the scripts also need to import those deps. But, pants-itself (ie rule code) shouldn't depend on those deps. I'm adding them in the

python-default

resolve to facilitate testing without contributing to an explosion in the number of resolves. (Plus, registering a lockfile in both a subsystem and as a resolve in pants own

pants.toml

would be sketchy)

I feel like we should be leveraging visibility rules harder, and I still think having 2-3 total resolves would be good. It's nice that Pants generally strips out unnecessary stuff (which is what I was seeing when I unpacked my venv), but from a maintenance POV, there really shouldn't be the case where someone isn't sure if they're performing an internal-only vs internal and "external" change

True, visibility rules are nice and could really help here. For multiple resolves, can we come up with a set of sane rules/guidelines to know when to use each resolve? Such guidelines would need to (at least) cover: • what to do with something (like the explorer backend) that should be distributed separately, but that needs to import code from pants itself. • what to do with build-support script deps when the build-support script (which is not distributable) needs to import code from pants • what to do with scripts distributed with pants (that get run in a cacheable subprocess as part of rule code) that can be nicely encapsulated under a subsystem + lockfile. • what to do with scripts distributed with pants (that get run in a cacheable subprocess as part of rule code instead of directly in rule code) that are only meant for use by pants, where having a configurable subsystem to change those dep versions makes no sense. How much pain are we willing to endure if pants code ends up in multiple resolves (because a script or backend needs to import from pants code)?

In this case, when you say build script - do you mean internal to Pants, or external?

build script = scripts under

build-support/