Per alcuni test funzionali, invoco un paio di utilità direttamente dalla directory del progetto, utilizzando Python subprocess.call (o check_call che invoca quest'ultimo). Funziona bene quando le librerie (PyYAML in particolare) sono installate globalmente. L'esecuzione in un virtualenv, come in Travis-CI, causa problemi, specialmente se virtualenv sta eseguendo Python 3.x e il Python globale è 2.7.virtualenv e subprocess.call() in ambiente misto Python 2.7/3.3
Se entrambi i Python sono 2.7, ho comunque dovuto iniettare la posizione di PyYAML all'interno del virtualenv, utilizzando l'argomento env su subprocess.call, per non causare un ImportError. Tuttavia, questo non funziona quando virtualenv è 3.x. Sembra le piste di utilità invocati al di fuori del virtualenv perché la sua sys.path appare come segue:
'/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']
Avviso la miscela di 2,7 e 3,3 sentieri, quest'ultimo espressamente iniettato come detto sopra.
C'è qualche modo da virtualenv o nelle funzioni subprocess per garantire che il processo secondario venga eseguito "all'interno" del virtualenv?
Puoi mostrarci il tuo codice per subprocess.call? – jterrace
Puoi trovare il codice [qui] (https://github.com/jmafc/Pyrseas/blob/master/pyrseas/testutils.py) nel '' DbMigrateTestCase.create_yaml'' (per esempio). –