Hi team, I have a case where running some test usi...
# general
w
Hi team, I have a case where running some test using pants fails. But if I use
--no-process-cleanup
, then run the
__run.sh
in the cached folder. The same test passed. I am wondering if
__run.sh
always give the consistent result compared to running
./pants test
?\
The reason it fails from pants test, is that it cannot find a module. It does not happen if I just use
__run.sh.
w
do you have any environment variables set in your shell which might impact `__run.sh`…? PYTHONPATH in particular. the sandbox will prune those, but it uses a different implementation than
__run.sh
, unfortunately
(check
env
)
w
I do have have a couple var in PYTHONPATH. but they are the exactly same as PEX_EXTRA_SYS_PATH in the __run.sh.
w
would try clearing the PYTHONPATH inside of
__run.sh
and see if you reproduce. Pants will not otherwise propagate the PYTHONPATH to a test.
w
so the pants does not use __run.sh?
w
correct.
it would be good to make those consistent: but currently there is no shell used at all when we invoke processes (unless
@rules
use one).
but avoiding assuming a shell is good… so if doing more filtering of your
env
vars in
__run.sh
helps to reproduce the issue you were seeing, then i’ll file a ticket to ensure that we’re filtering.
w
ok that makes sense. What about the the env if a process got created (i.e. subprocess.run) in a test running by pants? i feel that the env does not passed to the new process.
w
pants itself only handles passing environment variables to pytest: and it won’t pass ~anything other than those that have been configured: https://www.pantsbuild.org/docs/python-test-goal#setting-environment-variables if your test is spawning a subprocess, it would need to propagate the env itself
🙌 2
h
I've just found a case where a resolve fails, but if I run it with its
__run.sh
it succeeds. Digging further.