@enough-analyst-54434: regarding: https://github.com/pantsbuild/pants/blob/805d36e4df797f2405604feca10df9148f74244d/contrib/python/src/python/pants/contrib/python/checks/tasks/checkstyle/checkstyle.py#L155-L158 ... what is a valid reason for that to happen?

if pants is run from a pex only containing

pantsbuild.pants

? guessing

hm. it ... couldn't be, i think. because the code that is running is in the same module as the thing we're trying to resolve

i forget the package path but the pythonstyle checker is in its own package, separate from the

python

contrib module. if the

python

contrib module depends on the

checker

module, then maybe it's always going to be in scope

it's the same backend, and they depend on one another, so i think that they will both be there.

Aha. As explained in https://pantsbuild.slack.com/archives/C087V4P1T/p1555115862004400?thread_ts=1555086911.001100&cid=C087V4P1T sys.path pollution can come from the

PEX_INHERIT_PATH

env var being turned on and that could be done via

.pexrc

. If it turns out this is not what was going on, the only sane answer is a bug in pex

sys,path

scrubbing; although that has been solid afacit for several years now. Definitely worth an issue file with

PEX_VERBOSE=9

output and

PEX-INFO

contents if that last explanation resort is all we have left.

the other thing i was thinking was maybe that pants' own plugin loading might be injecting some other stuff... although i don't know why it would find some of the things it did. i'll look at it monday though. thanks!