virtualenv und subprocess.call() in gemischten Python 2.7/3.3 Umgebung

Question

Für einige Funktionstests, ich einige Dienstprogramme direkt aus dem Projektverzeichnis aufrufen, mit Python subprocess.call (oder check_call, die letzteres aufruft). Dies funktioniert gut, wenn die Bibliotheken (insbesondere PyYAML) global installiert sind. Das Laufen in einem virtualenv, wie unter Travis-CI, verursacht Probleme, besonders wenn der virtualenv Python 3.x und das globale Python 2.7 ausführt.

Wenn beide Pythons 2,7 sind, musste ich noch die Position von PyYAML innerhalb des virtualenv injizieren, unter Verwendung des env Arguments an subprocess.call, um keinen ImportError zu verursachen. Dies funktioniert jedoch nicht, wenn der virtualenv 3.x ist. Es scheint, das aufgerufene Dienstprogramm wird außerhalb des virtualenv weil seine sys.path sieht wie folgt aus:

'/home/travis/build/jmafc/Pyrseas/pyrseas', '/usr/local/lib/python2.7/dist-packages/distribute-0.6.35-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/pip-1.3.1-py2.7.egg', '/home/travis/build/jmafc/Pyrseas', '/home/travis/virtualenv/python3.3/lib/python3.3/site-packages', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages'] 

Hinweis über die Mischung von 2,7 und 3,3 Pfaden, wobei letztere ausdrücklich injiziert, wie erwähnt.

Gibt es einen Weg von entweder virtualenv oder in den subprocess Funktionen, um sicherzustellen, dass der Subprozess "innerhalb" des virtualenv läuft?

Answer 1

Wenn Sie eine Kopie Ihrer Umgebungsvariablen übergeben und den aktuellen Python-Interpreter als Ziel des Subprozesses verwenden, sollte die virtualenv-Umgebung erhalten bleiben. Etwas wie dieses:

subprocess.call([sys.executable, 'yourscript.py'], env=os.environ.copy())