https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

03/11/2020, 4:04 PM
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?
(I’m not sure the current union design would even allow this type of overriding)
w

witty-crayon-22786

03/11/2020, 4:05 PM
you'd need to subclass the target, i think.
šŸ‘ 1
h

hundreds-father-404

03/11/2020, 4:10 PM
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
w

witty-crayon-22786

03/11/2020, 4:11 PM
at some point, fields are a map from a string name to a type
šŸ‘ 1
so validating that string names don't collide is what would prevent that
šŸ‘ 1
(reflecting on union members, i guess)
...but yea, what you said about ignoring things you don't understand.