-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change_sys_path breaking virtualenv #1049
Comments
I believe this one might be a bug in remote execnet startup More investigation is needed |
I checked and the worker’s |
Thanks for the investigation I'll have to familiarize with that part |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello there.
I’m migrating a project that has been neglected for a while from pytest-xdist 1.30.0 to something less ancient and seeing a regression.
The project has a suite of tests that take quite a while to run. So we spawn a number of LXD containers, set up SSH on them, and use pytest-xdist to run tests in parallel on the lot of them:
The code under testing is installed in a virtualenv and we specify the full path to the virtualenv’s python executable. Issue #300 says this is expected to work.
The observed behavior is that during test collection stage the gw0 node fails to import modules installed in the venv, which leads to a discrepancy in collection results between gw0 and each of the rest of nodes. A debug
import sys; print(sys.path)
at the top of the file containing tests shows a list of directories that a non-virtualenv python would have.Further debugging has led me to #667. As I understand it, this saves the value of
sys.path
at the start of the main process, then restores that into eachpopen
worker but notssh
ones. I have tried augmenting thesys.path = change_sys_path
line with debug output and, sure enough, I see this:As a workaround, I can change
popen//
tossh=myproj.lxd//
so that the master py.test talks to all workers over ssh, even the local one:As another workaround I could probably run pytest using the master node’s virtualenv’s python:
The trashing of the virtualenv’s search path is quite surprising though.
The text was updated successfully, but these errors were encountered: