idea: Instead of relying on `` having a...
# plugins
idea: Instead of relying on
having a complete set of
could also take a list of dependencies with a
method (or, also maybe a backend_dependencies) Had to comment out most of all my rules, so I could do an
to get the latest changes in my IDE to make sure I'm changing the right things. And then other stuff was broken when re-enabling them 'big bang', so I've been sequentially enabling them to find out what's triggering issues. But so far I've spent my time chasing down dependencies than the one-broken-rule Would also be nice to have a
and a
so you can disable backends that define new target types and fields during an upgrade
for the first thing, a change like might help?
pretty much
if you lot could not be 5 steps ahead of me that'd be great.
😄 2
for unknown targets, there’s a flag for this internally already so would “just” need a flag to expose it as a public toggle
and for unknown fields, I think it would make most sense to filter out unknown fields in this Registrar class which is the primary bridge between the BUILD files and pants targets, and also knows about available fields