@witty-crayon-22786 re. https://github.com/pantsbuild/pants/pull/16840#pullrequestreview-1107949840 — I have a trivial reproduction case. At first glance this looks like a bug

Is it included in the "default" rules that a RuleRunner installs?

To be clear, the above change has nothing to do with Python bootstrap

Aren't the python bootstrap options the first/only ones included this way?

again, the above reproduction case has nothing to do with python bootstrap

python_bootstrap.py

is indeed always registered by

engine_initializer.py

and thus

RuleRunner

(give me 10-15 mins for another case)

It might also ease things to hold off on actually marking any/many options in the first PR

@witty-crayon-22786 the only changes I’ve made are changing the fields that @hundreds-father-404 had already added to use the new facility

ahhhhh I think I get it now. @ancient-vegetable-10556 I don't think any of this is a bug or unexpected: 1. The PluginField rules are going to be registered with RuleRunner because

python_bootstrap.py

gets registered in

engine_initalizer.py

2. But, when we in the test manually create a

LocalEnvironment()

target, it does not have those plugin fields registered because it is using the "core class" -- it doesn't consider plugin fields The real solution is to use

rule_runner.get_target()

on the relevant Address, rather than manually creating the Target instance. Then, no need for this scrubbing stuff

let me see if I can make that work

🚢

thanks!