wake-up-neo.com

Wohin in einer virtuellen Umgebung geht der benutzerdefinierte Code?

Welcher Art von Verzeichnisstruktur sollte man bei der Verwendung von virtualenv folgen? Wenn ich zum Beispiel eine WSGI-Anwendung erstellen und eine virtuelle Datei mit dem Namen foobar erstellen würde, würde ich mit einer Verzeichnisstruktur wie der folgenden beginnen:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}

Wenn diese Umgebung einmal erstellt ist, wo würde man ihre eigene platzieren:

  • python-Dateien?
  • statische Dateien (Bilder/etc)?
  • "Custom" -Pakete, wie sie online erhältlich sind, aber nicht im Käsegeschäft zu finden sind?

in Bezug auf die virtualenv Verzeichnisse?

(Angenommen, ich weiß bereits wohin die virtualenv-Verzeichnisse selbst gehen sollten .)

100

virtualenv stellt eine python Interpreterinstanz, keine Anwendungsinstanz dar. Normalerweise würden Sie Ihre Anwendungsdateien nicht in den Verzeichnissen erstellen, die das Standard-Python eines Systems enthalten Ihre Anwendung in einem virtualenv-Verzeichnis.

Beispielsweise könnten Sie ein Projekt haben, in dem Sie mehrere Anwendungen verwenden, die dieselbe virtuelle Umgebung verwenden. Oder Sie testen eine Anwendung mit einer virtuellen Umgebung, die später mit einem System-Python bereitgestellt wird. Möglicherweise packen Sie auch eine eigenständige App, bei der es möglicherweise sinnvoll ist, das Verzeichnis virtualenv irgendwo im App-Verzeichnis selbst zu haben.

Im Allgemeinen glaube ich nicht, dass es eine richtige Antwort auf die Frage gibt. Und das Gute an virtualenv ist, dass es viele verschiedene Anwendungsfälle unterstützt: Es muss keinen richtigen Weg geben.

82
Ned Deily

Wenn Sie nur ab und zu ein paar Projekte haben, hindert Sie nichts daran, eine neue virtuelle Umgebung für jedes einzelne zu erstellen und Ihre Pakete direkt darin abzulegen:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}
  /mypackage1
    __init__.py
  /mypackage2
    __init__.py

Der Vorteil dieses Ansatzes ist, dass Sie immer sicher sein können, das zum Projekt gehörende Aktivierungsskript zu finden.

$ cd /foobar
$ source bin/activate
$ python 
>>> import mypackage1
>>>

Wenn Sie sich für eine etwas bessere Organisation entscheiden, sollten Sie in Betracht ziehen, alle Ihre virtuellen Dateien in einem Ordner abzulegen und sie nach dem Projekt zu benennen, an dem Sie gerade arbeiten.

  /virtualenvs
    /foobar
      /bin
        {activate, activate.py, easy_install, python}
      /include
        {python2.6/...}
      /lib
        {python2.6/...}
  /foobar
    /mypackage1
      __init__.py
    /mypackage2
      __init__.py

Auf diese Weise können Sie immer mit einer neuen virtuellen Umgebung beginnen, wenn etwas schief geht, und Ihre Projektdateien bleiben sicher.

Ein weiterer Vorteil ist, dass mehrere Ihrer Projekte dieselbe virtuelle Umgebung verwenden können, sodass Sie nicht immer wieder dieselbe Installation durchführen müssen, wenn Sie viele Abhängigkeiten haben.

$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python 
>>> import mypackage2
>>>

Für Benutzer, die regelmäßig virtuelle Envs einrichten und entfernen müssen, ist es sinnvoll, sich den virtuellen Envwrapper anzusehen.

http://pypi.python.org/pypi/virtualenvwrapper

Mit virtualenvwrapper können Sie

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

Sie müssen sich keine Gedanken mehr darüber machen, wo sich Ihre virtuellen Umgebungen befinden, wenn Sie an den Projekten "foo" und "bar" arbeiten:

  /foo
    /mypackage1
      __init__.py
  /bar
    /mypackage2
      __init__.py

So fängst du an, am Projekt "foo" zu arbeiten:

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

Dann ist der Wechsel zum Projekt "bar" so einfach:

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

Ziemlich ordentlich, nicht wahr?

53
Maik Röder

Da Virtualenvs nicht verlagerbar sind, ist es meiner Meinung nach eine schlechte Praxis, Ihre Projektdateien in einem Virtualenv-Verzeichnis abzulegen. Das Virtualenv selbst ist ein generiertes Entwicklungs-/Bereitstellungsartefakt (ähnlich einer .pyc-Datei), das nicht Teil des Projekts ist. Es sollte einfach sein, es wegzublasen und jederzeit neu zu erstellen oder ein neues auf einem neuen Bereitstellungshost zu erstellen.

Tatsächlich verwenden viele Benutzer virtualenvwrapper , wodurch die tatsächlichen virtuellen Envs fast vollständig aus Ihrem Bewusstsein entfernt werden und standardmäßig alle nebeneinander in $ HOME/.virtualenvs platziert werden.

28
Carl Meyer

Wenn Sie Ihrem Projekt einen setup.py geben, kann pip es direkt aus der Versionskontrolle importieren.

Mach so etwas:

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#Egg=proj

Der -e fügt das Projekt in myproject/src ein, verknüpft es jedoch mit myproject/lib/pythonX.X/site-packages/, sodass alle Änderungen, die Sie vornehmen, sofort in Modulen übernommen werden, die es aus Ihrem importieren local site-packages. Das #Egg -Bit teilt pip mit, welchen Namen Sie dem von ihm erstellten Eipaket geben möchten.

Wenn Sie --no-site-packages nicht verwenden, müssen Sie mit der Option -E angeben, dass pip in die virtuelle Umgebung installiert werden soll

2
jcdyer