(1) allow de-registering specific `@rule`s (not in...
# development
(1) allow de-registering specific `@rule`s (not intrinsics) (2) allow "patching" specific A -> B subgraphs spanned by a specific new rule or set of rules (3) swap out exactly one rule with exactly another, with the same params and return type
💯 1
Agreed! This is really really powerful to let users change the core internal rules (outside of intrinsics)! Of course, it’s a very advanced feature and users need to make sure their new implementation still works, but it’s powerful that we even allow this.
and also
i'm 10000% coming around to the idea of "truly extensible" now
now that i think about it more this is definitely a really powerful feature that not a lot of other tools would provide, or would provide in a way that makes people happy instead of sad
❤️ 1
i'd also love to be able to swap out intrinsics too and in general define a way to write rust rules outside of the pants repo though :) just think that might be useful to push down the road
🔥 1
Sort of related. We talked about JavaScript support again in a recent meeting and realized how, regardless of how comprehensive and good our JS implementation is, we will not be able to cover all JS needs because the ecosystem is so huge and changes so rapidly. Us trying to implement the perfect plugin is the wrong approach, arguably. Instead, our focus should be on making it exceptionally intuitive and easy for users to write an implementation for their precise needs. And then, for them to share it with others. Tl;dr: the extensibility of V2 is arguably its killer feature. You can wrap any build process with V2 Pants to get for no extra work a) sane caching, b) high parallelism, c) remote execution, and d) general Pants benefits like understanding how your dependencies relate.