Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

but... wtf. how is that not breaking... everything? heh

that doesn't make sense. i have two references to what i think are the same class

that in itself shouldn't be possible, whether or not their ids changed (although i don't think they should be able to anyway... memory addresses shouldn't change during a fork)

I don’t think they’d change, but any re-evaluation/reimport of python code might create new copies with disparate mem addrs?

can confirm though. could be something like that

```&gt;&gt;&gt; &lt;class 'pants.backend.graph_info.tasks.listtargets.ListTargets_list'&gt; type(x) &lt;class 'pants.backend.graph_info.tasks.listtargets.ListTargets_list'&gt; ??: &lt;class 'abc.ABCMeta'&gt; &lt;class 'abc.ABCMeta'&gt;```

going to just bisect along the path that this object exists

From this right?: <https://github.com/jsirois/pants/blob/327a8d989f986623b258d5926142333d80697e4c/src/python/pants/goal/goal.py#L182>

Off the top it makes sense types created via type(...) won't be ==

specifically, this code is failing to do a dict lookup for something that is clearly in the dict: <https://github.com/pantsbuild/pants/pull/5639/files#diff-d1a67a2ed83d672d382c231d19c1c05bR171>

i see what you're saying though. that code might be running twice

so... we do have handling for that somewhere, iirc