was debugging the above, kept getting

Exception message: Build graph construction failed: ExecutionError 1 Exception raised in CFFI extern methods:
Traceback (most recent call last):
  File "/container/workdir/src/python/pants/engine/native.py", line 669, in identify
    hash_ = hash(obj)
TypeError: unhashable type: 'list'

...

Exception: Types that will be passed as Params at the root of a graph need to be registered via RootRule:
  Any

and had absolutely no context for where it was coming from, until i manually added a `try`/`except TypeError as e` block into

identify()

in

native.py

, which finally gave me:

Traceback (most recent call last):
  File "/container/workdir/src/python/pants/engine/native.py", line 337, in extern_identify
    return c.identify(obj)
  File "/container/workdir/src/python/pants/engine/native.py", line 671, in identify
    raise Exception(f'obj = {obj} ({type(obj)}), e = {e}') from e
Exception: obj = [Specs(dependencies=(SingleAddress(directory='src/python/pants', name='pants-packaged'),), matcher=SpecsMatcher(tags=(), exclude_patterns=()))] (<class 'list'>), e = unhashable type: 'list'

this actually wasn't the real error -- the real error was when i accidentally passed in a list of

Specs

to

TargetRoots

, instead of a single

Specs

. the previous run-time type checking would have caught this for me at the precise point of failure. the reason i added types to

datatype()

in the first place was so we didn't have to manually insert print statements everywhere, especially when debugging failures coming from the engine, especially when debugging failures running pants in our internal CI. i guess i can try adding

partially_type_checked

to the targets owning

specs.py

,

target_roots_calculator.py

, and

query.py

(a new file i've added)? but i really need to make sure that every constructor is type-checked in order to avoid passing in a

list

instead of a

Specs

, so i guess i really need to wait until everything is

type_checked

? would have been cool if we could have made it clear that that's what's necessary to achieve the prior level of type safety. i absolutely think mypy is the right way to go, but i thought the reason for that was so that we could get more type safety with less effort, and i'm now concerned that we're approaching an interim period of less type safety without realizing it. would people accept (multiple, separate) PRs that attempted to color everything

type_checked

if i decided to work on that in the background this week (without any attempt at refactoring, etc)? is there anything i need to know before doing this?