Followup question on extensibility of target API. We agreed that we care about being able to add custom fields to pre-existing core target types, like adding a bool field

type_checked

to

python_library

. Do we care about being able to replace a pre-existing field on a core target type with your own custom implementation? Do we want to allow you to replace how

compatibility

and

sources

behave for something like

python_library

? Or, would you need to create a new target type like

python3_library

,

python23_library

, and

python2_library

in order to override a field already defined on that target?

you'd need to subclass the target, i think.

Cool, I agree. I think that not allowing overriding will be important for the validity of Pants. If core Pants defines

Compatibility

to always work a certain way, we rely on that assumption throughout the codebase. Users being able to override the field so that now, for example, it stores a

bool

rather than

List[str]

, would break a bunch of code. In contrast, adding a new field is safe because core Pants will simply ignore that field

at some point, fields are a map from a string name to a type