2016-08-08 30 views
1

So habe ich virtualenv verwendet, um Umgebungen für eine Anzahl von Projekten zu definieren, an denen ich arbeite. Ich habe den Python virtualenv als Version 3.4 definiert. Schließlich wurde mein globales Python von 3.4.0 auf 3.4.3 aktualisiert. Dies erwies sich als ein Problem, weil die virtualenv war abhängig von den globalen Binärdateien (der Inhalt von /lib/python3.4 in meinem virtualenv ist eigentlich nur Links zu den globalen Binärdateien), und diese sind nicht definiert, bis zu ihren Nebenversionen. Mit anderen Worten, als das Upgrade durchgeführt wurde, wurde der Inhalt des Binärordners /usr/lib/python3.4 ersetzt. Dies liegt daran, dass Python die Dinge nicht separat in 3.4.0 und 3.4.3 installiert, sondern nur in einem einzigen Ordner mit dem Namen /usr/lib/python3.4. Da die ausführbare Python-Datei in meinem virtualenv 3.4.0 war, gab es offensichtlich Kompatibilitätsprobleme mit den 3.4.3-Binärdateien (es würde ctypes nicht laden, was fast alles verhinderte, was python-abhängig war). Die einzige Lösung, die ich gefunden habe, ist das Downgrade meiner globalen Python-Installation, aber das fühlt sich "dreckig" an. Was wäre, wenn ich ein Projekt mit 3.4.0 und ein weiteres mit 3.4.3 hätte? Gibt es keine Möglichkeit, sie auf demselben Rechner parallel arbeiten zu lassen, da nur ein einziger Binärordner für eine 3.4.x-Installation existieren kann?Verwende ich virtualenv falsch oder ist das eine Einschränkung davon?

Ich versuche zu verstehen, wenn ich etwas offensichtliche hier vermisse oder wenn dies ein häufiges Problem mit virtualenv ist, angesichts der Tatsache, dass ich einige Leute über Probleme mit binares bei der Verwendung von virtualenv zu beschweren habe gehört.

In der Zukunft, gibt es sowieso virtualenvwrapper zu erzählen, die Binärdateien zu kopieren, anstatt mit ihnen zu verknüpfen?

+0

Ist das Problem mit Python 3.4.3 unvereinbar mit Ihrem Code oder ist es nur die virtualenv versagt (neu erstellen die virtualenv und neu installieren alles darin behebt es)? –

+0

Das Problem ist nicht mit meinem Code. Selbst das Laden eines Python-Interpreters in das virtuelle env schlägt fehl, wenn ich versuche, grundlegende Bibliotheken zu laden. Es läuft also alles gut, bevor die Details meines Codes ins Bild kommen. Es geht darum, eine ausführbare Datei mit den falschen Binärdateien auszuführen. – ticster

+0

Was ist, wenn du ein neues virtualenv erstellst und Python 3.4.3 dort verwendest? –

Antwort

2

Virtualenvs wurden nicht als tragbar konzipiert, sowohl auf Maschinen als auch auf Python-Versionen.

Dies bedeutet Upgrade Python-Versionen bricht manchmal virtualenvs. Sie müssen sie neu erstellen und in der es (laufen diese in Ihrem virtualenv root) alles neu zu installieren:

# Save a list of what you had installed 
pip freeze > freeze.txt 

# Trash the entire virtualenv 
deactivate 
rm -rf lib/ bin/ share/ man/ include/ .Python pip-selfcheck.json 

# Create it anew 
virtualenv . 

# Install all libraries you had before 
pip install -r freeze.txt 
+0

"Upgrade von Python-Versionen bricht manchmal virtualenvs." Dies beantwortet meine Frage. Ich bin mir bewusst, dass ich jedes virtualenv individuell mit einem verbesserten Python nachbilden kann, aber es scheint mir, dass dies den gesamten Zweck der Verwendung von virtualenv an erster Stelle zunichte macht ... Aber wenn Python wirklich zu verbessern bricht virutalenv dann scheint es ich, dass dies eine starke Einschränkung davon ist. – ticster

+1

Virtualenvs wurden nicht als tragbar konzipiert, weder auf Rechnern noch in Python-Versionen. Es ist ein bekannter Nachteil, aber verfehlt seinen Zweck nicht. –

+0

Gotcha. Ich habe mir gedacht, dass es Ihnen erlaubt, eine Python-Version anzugeben, die eine globale Änderung in Python-Versionen ermöglicht, während Sie eine lokal-statische beibehalten. Ich denke nicht, und es geht nur darum, externe Modulversionen zu handhaben. Danke für die Hilfe. Könnten Sie diesen Kommentar einfach in Ihrer Antwort hinzufügen? Weil das wirklich zu dem kommt, was ich frage. Ich kann dann die Antwort akzeptieren. – ticster