Did another test with `repl` ``` xxx@yyy:~/zzz$ ....
# general
c
Did another test with
repl
Copy code
xxx@yyy:~/zzz$ ./pants repl zirak/src/python/example:hello2
Python 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
Type "copyright", "credits" or "license" for more information.

IPython 1.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import sys
In [2]: [k for k in sys.modules.keys() if "jinja2" in k]
Out[2]:
['jinja2.collections',
 'jinja2.cPickle',
 'jinja2.errno',
 'jinja2.lexer',
 'jinja2.threading',
 'jinja2.compiler',
...
Question is how does these modules get populated?
e
The answer is complicated. It probably makes most sense to open an issue and include your
./pants --version
as well as output of
PEX_VERBOSE=9 ./pants repl zirak/src/python/example:hello2
. The
PEX_VERBOSE=9
env car should produce alot of logging that makes more clear what is going on. In particular, PEX, which pants uses for the repl environment, should isolate that environment from your dev environment even though it's apparently not doing so. The PE_VERBOSE output will help pinpoint the leak is, as you expect, in your local dev environment.
c
Thanks for reply, I opened an issue with more details: https://github.com/pantsbuild/pants/issues/8557
Indeed a pex issue, I think. The
minimum_sys_modules()
(https://github.com/pantsbuild/pex/blob/master/pex/pex.py#L184-L203) will drop the tainted packages but keep the tainted modules which are not packages (
Jinja2.utils
in this case)