Das deutsche Python-Forum

Hi,

folgendes Problem:

Auf der Entwicklungsmaschine ist mein Projekt (inkl Python) ausgecheckt in einem bestimmteten Pfad, z.B.

c:\my_projects\tool4712

Darin liegt dann auch der Python-Interpreter, z.B. etwa so:

c:\my_projects\tool4712\Python27_amd64\python.exe

Ein paar Tools, die wir benötigen, wurden mit pip installiert:

pip install virtualenv.

Unter Windows liegen dann ja in einem Scripts-Unterverzeichnis entsprechende .exe-Dateien, z.B.

c:\my_projects\tool4712\Python27_amd64\Scripts\virtualenv.exe

(nur ein Beispiel). Das funktioniert auch auf der Entwicklungsmaschine.

Später wird das auf der Buildmaschine in einen anderen Pfade ausgecheckt, z.B.

c:\automated_builds\tool4712

Das ändert dann auch den Pfade des inhaltenen Python-Interpreters:

c:\automated_builds\tool4712\Python27_amd64\python.exe

c:\my_projects\tool4712\Python27_amd64\python.exe

ist in dieser Umgebung nicht verfügbar. Versuche ich jetzt hier virtualenv aufzurufen, kommt sowas:

Fatal error in launcher: Unable to create process using '"c:\my_projects\tool4712\Python27_amd64\python.exe" "c:\automated_builds\tool4712\Python27_amd64\Scripts\virtualenv.exe"

Der Grund ist offensichtlich, dass pip beim Installieren den Pfad des gerade verwendeten Python-Interpreters hier mit hineinschreibt.

Ich kann dieses Problem dadurch beheben, dass ich in dem Binary

"!c:\my_projects\tool4712\Python27_amd64\python.exe"

ersetze durch

"!python"

Das ist aber natürlich nicht schön. Gibt es da vielleicht einen anderen Weg, z.B. pip zu sagen, dass der Pfad da nicht hineingeschrieben werden soll, oder anzugeben, dass kein absoluter Pfad verwendet werden soll o.ä.?

Eine Alternative wäre natürlich, diese .exe-Wrapper gar nicht zu verwenden, sondern die betreffenden Tools mit

python c:\automated_builds\tool4712\Python27_amd64\Lib\site-packages\virtualenv.py

zu starten, aber das ist dann doch etwas unhandlich.

Für jeden Tipp dankbar

slash

Es gibt diverse Loesungen hier. Keine so wie du es dir wuenschst. Ein virtualenv ist ein vergaengliches Ding, und nicht dazu gedacht, auf Dauer zu leben, oder durch die Gegend gereicht zu werden. Was uebrigens auch bedeutet, das es nicht in das Repository gehoert!

Wege, wie mit der Situation umgegangen werden kann:

- Teil des Deploymens ist die Anlage eines neuen venvs. Das zwingt dich dazu, die Abhaengigkeiten sauber zu pflegen. Es gibt verschiedene Moeglichkeiten, simple requirements.txt und pip, oder pipenv, oder pyenv etc.
- Du deployst durch Docker, und auch da ist die Anlage des venvs teil des Dockerfiles.
- Du hast ein bestehendes virtualenv auf der Zielmaschine, und das wird sukkzessive geupdated, und nur der eigentliche Projektcode via GIT oder was auch immer synchron gehalten. Das ist IMHO die schlechteste Variante, weil Unterschiede in den venvs auftauchen koennen, und man immer wieder mal Hand anlegen muss.

Also in Summe: schmeiss die venvs grosszuegig weg, und investier in die Reproduzierbarkeit des aufsetzen des Systems. Hilft auch Kollegen die neu ins Projekt kommen, etc.