Do we want to elevate a mechanism for required fields? Concrete example:

alias()

must have the field

target

defined. We could achieve this ad hoc, but do we anticipate this being a useful mechanism? For example, if we elevate it, then we can do nice things like say

required

in the output of

./v2 target-types

Yessssssssssssss

See https://github.com/pantsbuild/pants/pull/9392 for required fields 🙂 We already enforce that Python target types must end in

.py

, but that’s an interesting idea to generalize the mechanism! That’s very easy to do!

We already enforce that Python target types must end in

.py

,

I think we enforce that for source files, but not dependencies. I think I can write:

python_library(dependencies = [":some_java_library"])
java_library(name = "some_java_library"])

And everything will be fine and the dep will just be ignored, which is kind of bad

Oh, correct. I see what you mean. That would be a great mechanism! NB that you need to make exceptions for

Files

and

Resources

, but that’s achievable. It gets a little awkward that you can’t say

assert isinstance(tgt, Files)

because that breaks custom target types like

CustomFiles

, given the field-driven nature of the API. But, we could do

assert tgt.has_field(FilesSources)

as a proxy to know it’s a Files target

An interesting problem to design, for sure 🙂