web-dev-qa-db-fra.com

Où dans un virtualenv le code personnalisé va-t-il?

Quel type de structure de répertoire doit-on suivre lors de l'utilisation de virtualenv? Par exemple, si je construisais une application WSGI et créais un virtualenv appelé foobar je commencerais avec une structure de répertoire comme:

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

Une fois cet environnement créé, où placer le sien:

  • fichiers python?
  • fichiers statiques (images/etc)?
  • des forfaits "sur mesure", comme ceux disponibles en ligne mais introuvables dans la fromagerie?

par rapport aux répertoires virtualenv?

(Supposons que je sache déjà où les répertoires virtualenv eux-mêmes devraient aller .)

pythonprojectvirtualenv
100
Phillip B Oldham

virtualenv fournit une instance d'interpréteur python, pas une instance d'application. Normalement, vous ne créeriez pas vos fichiers d'application dans les répertoires contenant le Python par défaut d'un système, de même il n'est pas nécessaire de localiser votre application dans un répertoire virtualenv.

Par exemple, vous pouvez avoir un projet dans lequel vous avez plusieurs applications utilisant le même virtualenv. Ou, vous testez peut-être une application avec un virtualenv qui sera ensuite déployé avec un système Python. Ou, vous pouvez empaqueter une application autonome où il pourrait être judicieux d'avoir le répertoire virtualenv situé quelque part dans le répertoire de l'application elle-même.

Donc, en général, je ne pense pas qu'il y ait une bonne réponse à la question. Et, une bonne chose à propos de virtualenv est qu'il prend en charge de nombreux cas d'utilisation différents: il n'est pas nécessaire qu'il y ait une seule bonne façon.

82
Ned Deily

Si vous n'avez que quelques projets de temps en temps, rien ne vous empêche de créer un nouveau virtualenv pour chacun et de placer vos packages à l'intérieur:

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

L'avantage de cette approche est que vous pouvez toujours être sûr de trouver le script d'activation qui appartient au projet à l'intérieur.

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

Si vous décidez d'être un peu plus organisé, vous devriez envisager de mettre tous vos virtualenvs dans un dossier et de nommer chacun d'eux d'après le projet sur lequel vous travaillez.

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

De cette façon, vous pouvez toujours recommencer avec un nouveau virtualenv lorsque les choses tournent mal et que vos fichiers de projet restent en sécurité.

Un autre avantage est que plusieurs de vos projets peuvent utiliser le même virtualenv, vous n'avez donc pas à refaire la même installation encore et encore si vous avez beaucoup de dépendances.

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

Pour les utilisateurs qui doivent régulièrement installer et démonter virtualenvs, il serait judicieux de regarder virtualenvwrapper.

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

Avec virtualenvwrapper, vous pouvez

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

Vous n'avez plus à vous soucier de l'emplacement de vos virtualenvs lorsque vous travaillez sur les projets "foo" et "bar":

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

Voici comment vous commencez à travailler sur le projet "foo":

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

Passer au projet "bar" est aussi simple que cela:

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

Assez bien, non?

53
Maik Röder

Parce que virtualenvs ne sont pas déplaçables, à mon avis, il est inapproprié de placer vos fichiers de projet dans un répertoire virtualenv. Le virtualenv lui-même est un artefact de développement/déploiement généré (un peu comme un fichier .pyc), ne faisant pas partie du projet; il devrait être facile de le supprimer et de le recréer à tout moment, ou d'en créer un nouveau sur un nouvel hôte de déploiement, etc.

En fait, beaucoup de gens utilisent virtualenvwrapper , ce qui supprime presque complètement les virtualenvs réels de votre conscience, en les plaçant tous côte à côte dans $ HOME/.virtualenvs par défaut.

28
Carl Meyer

Si vous donnez à votre projet un setup.py, pip peut l'importer directement depuis le contrôle de version.

Faites quelque chose comme ça:

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

Le -e mettra le projet dans myproject/src, mais associez-le à myproject/lib/pythonX.X/site-packages/, donc toutes les modifications que vous apporterez seront immédiatement récupérées dans les modules qui l'importent depuis votre _ site-packages. Le #Egg bit indique à pip le nom que vous souhaitez donner au package Egg qu'il crée pour vous.

Si vous n'utilisez pas --no-site-packages, veillez à spécifier que vous souhaitez que pip installe dans virtualenv avec le -E option

2
jcdyer