https://pantsbuild.org/ logo
Join Slack
Powered by
Do we have a way to deregister a rule? E.g., if a ...
# development
h
Do we have a way to deregister a rule? E.g., if a custom plugin wants to override a rule implementation?
w
we do not. so far the approach has been to declare 
@unions
in places where people can plug in logic, rather than replacing things.
…and if that’s possible for the usecase, it’s probably preferable.
h
Yeah, that's been my approach so far (this is re custom logic for computing setup-py kwargs, such as 
version
, in a `python_distribution`'s 
provides=
field.)
w
would look at AsyncField, as it was how eric expected that custom logic to construct fields would be plugged in
👍 2
or the macro stuff i mentioned.
i think that we might eventually need to provide the ability to de-register a rule, as an escape hatch for things that haven’t been made explicitly pluggable, but avoiding doing that for as long as we can would be great.
h
No, I’ve been wanting this mechanism for a while though. I think it will make it feasible for users to swap out built in rules for their own version
With an AsyncField, it’s important tho that there’s only one rule to hydrate that field. That’s key to the Target API working with subclassibg a field. So, the field author should expose certain entry points that subclasses can implement. For example, the Sources field has the entry point validate_snapshot(), which gets called in the hydration rule
w
https://pantsbuild.slack.com/archives/C0D7TNJHL/p1598485364046600?thread_ts=1598478454.043400&cid=C0D7TNJHL it’s a bit like monkey-patching. it’s helpful as a stopgap until a true extension point is added, but you don’t want to do it in the long term.
h
Yes for sure it’s monkey patching. It’s really powerful that python lets you monkey patch. Agreed that we should err on the side of proper extensions, but there will always be rules we don’t want to extend. For example, you may want to change how the SourceFiles rule works
w
if you do that, and upstream never hears about it, it is very likely to break during the next release
(we’re in agreement i think. i’m just trying to highlight the extent to which it is a stopgap until something can be upstreamed/made extensible)
…which is why leaning on it now, when we have the most flexibility to adjust the plugin API to enable this kind of usecase, would be a bad idea i think.
Open in Slack
PreviousNext
Powered by