https://pantsbuild.org/ logo
Join Slack
Powered by
Do we actually care about a plugin author being ab...
# development
h
Do we actually care about a plugin author being able to add additional fields to a built-in core target types like 
python_library
? For example, do we want plugin authors to be able to add a boolean field 
type_checked
to every 
python_library
? Or, do we expect them to develop a new custom type like 
typed_python_library
?
V1 does not allow changing the built-in targets afaict; you must subclass and have a new target type The current sketch of V2 Target API allows adding additional fields to pre-existing targets. But, I think we can simplify it by removing that functionality (still early in the experiment) cc @happy-kitchen-89482 @witty-crayon-22786
h
I think being able to add fields to existing targets makes sense
E.g., if a custom goal needs extra information, we don't want to force a new type. Especially if two unrelated custom goals each need different extra information, which type would you even choose then?
👍 1
This would be like "tags" but waaaay better, since your custom fields would be first-class things
👖 1
🔥 1
So yes I think we do care
h
I agree. It would be an awesome feature to be able to add the bool field 
type_checked
to 
python_library
, 
python_tests
, etc without any changes to core Pants. Core Pants will still behave the same way because it doesn’t ever try to consume the new field, but your custom Plugin now has a first-class way to do consume that new field
@dry-analyst-73584 raised some valid points about the tradeoff that this results in the code being less easy to understand and debug. Here, I think the extensibility is worth it (much better tags would be incredible), and I think we can reduce the negative impact Generally, I added a new goal to the design doc called “Easy to debug”. I think we will frequently run into the tradeoff between “Easy to debug” vs. “Extensible” in this project
w
adding additional fields to targets is a really common thing that folks want to do in plugins
💯 1
people attempt to do it with 1) data stored in tags (a bit awkward and schemaless, but doesn't require subclassing), 2) subclassing (which breaks anything that is based on exact type matches, which are fairly common)
👍 1
that was one of the reasons behind having a union of the legal fields... so that it can be extended at runtime
h
Awesome, thank you both! (And to Tansy for the very valid concerns)
that was one of the reasons behind having a union of the legal fields... so that it can be extended at runtime
Right. This was the part that I was playing devils advocate if we could avoid. Looks like, no
w
i think that generating docs for both 1) unions themselves, 2) known union members ... will be really critical to explaining and authoring plugins... and it should lead naturally to a clean way to generate the BUILD dictionary like we do on the site now
💯 1
@dry-analyst-73584: agreed that people are more familiar with subclassing... but explaining "how do i know which fields are legal for a target in my BUILD file" and "how do i make an additional field legal" is i think easier to explain with unions and fields than it is with subclassing... maybe.
👍 2
(who is 
@Tony
, heh. oops!)
😂 1
h
but explaining “how do i know which fields are legal for a target in my BUILD file” and “how do i make an additional field legal” is i think easier to explain with unions and fields than it is with subclassing... maybe.
I think so too. The main point that Tansy made is how difficult it is with Target Adaptors to call 
dir(my_adaptor)
and see what all the fields are. We should ensure there’s an ergonomic way to say ~`my_target.all_valid_fields` for the sake of debugging I think that’s solvable
💯 1
🙏 1
w
true. but the flipside is 
dir(my_adaptor)
also renders a bunch of stuff that is not relevant to the target
because inheritance conflates a lot of things.
👍 2
Open in Slack
PreviousNext
Powered by