Question re named resolves configuration. Currently #12734 implements named resolves under

python-setup

, with the intention of

./pants generate-lockfiles

being the one command we use to do resolves for all languages. Following that pathway, when we add named resolves to JVM, we’d add named resolves under

jvm-setup

and

./pants generate-lockfiles

would resolve both python and JVM locks. The issue here is that because the JVM lock and python lock configs are disjoint, you can specify the same name for a JVM resolve and a Python resolve. I have a couple ideas for how we could fix this: 1. Have all resolves under the same config, and require users to specify what subsystem a lock applies to 2. Keep resolves under each subsystem’s configs, and require an option to specify which subsystem to resolve when running

generate-lockfiles

(i.e. if pants discovers a Python and JVM lock, it errors, and tells users to specify which subsystem we meant, or to resolve both of them) Any thoughts? Other ideas on how to approach this?

Option 3: Eagerly validate that resolve names are unique across languages. When you try adding a new resolve, Pants will error saying to either choose a name or rename the existing one Note that this can only be a problem when adding new resolves, which is not common to do and usually done by an admin.

It would need to be invalid to name your resolves the same as a tool resolve

It is already invalid to do that. Although I don't know if our validation is as eager as it needs to be there, might not error till you run

generate-lockfiles

Which maybeee is fine? Presumably when you're adding a new resolve, you will run

generate-lockfiles

Right, and if you say a given target needs a specific resolve, you’ll probably end up with unmet dependencies

another option would be to pivot again to having resolve targets for user code (but not tools, yet). then the identity of the resolve is the target’s address.

@witty-crayon-22786 I don’t think we want that. That would mean there’d be an (expensive) resolve per target, and make it difficult to ensure related targets have compatible resolves

sorry, what i mean is

coursier_resolve(name='x')

declared in a BUILD file… it wouldn’t change the total resolve count

I do really like all your resolves being declared in one single place in

pants.toml

. It makes sure that codebase admins will be aware of adding a new resolve, which is a very costly decision This is also why I love the idea of named interpreter constriants so much

Yeah, I think Eric raises a good point about the cost of adding new resolves

another concern for cross-language named resolves is just needing uniform options to represent thirdparty resolves across all languages

what do you mean there?

…but i guess that you’ve addressed that above by having the different languages declare their resolves on their own subsystems?

Following up: I think Eric’s suggestion that we eagerly validate that lockfiles don’t have names that clash makes the most sense at this point, so that’s what I’ll aim towards to start off with