2017-12-12 7 views
0

Gibt es eine Möglichkeit, die virtualenv auf dynamische Weise zu laden?Django.fcgi mit dynamischen virtualenv

#!/home/root/.virtualenvs/production/bin/python 

import os, sys 
... 

würde ich den Weg gerne

#!/home/root/.virtualenvs/production/bin/python oder #!/home/root/.virtualenvs/staging/bin/python abhängig sein, wenn der Ordnername staging oder production ist

Ich kann den Ordnernamen auf diese Weise erhalten:

_PROJECT_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) 
sys.path.insert(0, _PROJECT_DIR) 
sys.path.insert(0, os.path.dirname(_PROJECT_DIR)) 

_FOLDER_NAME = _PROJECT_DIR.split('/')[-1] 

Aber ich habe keine Ahnung, ob ich den virtualenv auf dieser Basis dynamisch laden kann.

Es ist ein Bereitstellungsproblem, ich muss derzeit den Pfad in Staging-Umgebung ersetzen, da es für die Produktion fest codiert ist.

Antwort

1

Warum nicht env verwenden?

#!/usr/bin/env python 

Und dann führen Sie Ihre Anwendung aus der entsprechenden Umgebung?

+0

Ich verstehe nicht ganz, was das tut. Würde sich die 'Python'-Binärdatei abhängig von der Virtualenv ändern, mit der ich arbeite, dynamisch? Wie wäre es, wenn 'source ~/.virtualenvs/staging/bin/activate' und dann'/usr/bin/env python 'die ausführbare Python-Datei von' staging' virtualenv wäre? – Vadorequest

+1

'env' erlaubt Ihnen, den entsprechenden Python-Interpreter entsprechend der Umgebung, in der Sie arbeiten, abzurufen und zu starten (hängt von der Umgebungsvariablen $ PATH ab). Dies wird oft für Skripts verwendet, wenn Sie nicht sicher sind, auf welchem ​​Pfad sich der Interpreter auf Ihrem System befindet. – vmonteco

+1

Dann, wenn Sie Ihr Skript nicht von einem virtualenv starten, sollte es den System-Interpreter verwenden und wenn Sie es von einem virtualenv starten, sollte es den Interpreter dieses virtualenv verwenden. – vmonteco