¿Dónde en un virtualenv va el código personalizado?

Question

¿Qué tipo de estructura de directorios se debe seguir al usar virtualenv? Por ejemplo, si estuviera construyendo una aplicación WSGI y creó un virtualenv llamada foobar Me gustaría empezar con una estructura de directorios como:

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

Una vez creado este entorno, donde habría un solo lugar su propia:

• archivos python?
• archivos estáticos (imágenes/etc)?
• paquetes "personalizados", como los disponibles en línea pero que no se encuentran en la tienda de quesos?

en el directorio virtualenv?

(se supone que ya sé where the virtualenv directories themselves should go.)

Answer 1

virtualenv proporciona una instancia de Python intérprete, no una instancia de aplicación. Normalmente no crearía sus archivos de aplicación dentro de los directorios que contienen el Python predeterminado de un sistema, tampoco es necesario ubicar su aplicación dentro de un directorio virtualenv.

Por ejemplo, es posible que tenga un proyecto en el que tenga varias aplicaciones utilizando el mismo virtualenv. O bien, puede probar una aplicación con un virtualenv que luego se implementará con un sistema Python. O bien, puede empaquetar una aplicación independiente donde podría tener sentido tener el directorio virtualenv ubicado en algún lugar dentro del directorio de la aplicación.

Por lo tanto, en general, no creo que haya una respuesta correcta a la pregunta. Y, algo bueno acerca de virtualenv es que admite muchos casos de uso diferentes: no es necesario que haya una forma correcta.

Answer 2

Si sólo tiene unos pocos proyectos de vez en cuando, nada le impide la creación de un nuevo virtualenv para cada uno, y poner tus paquetes en el interior:

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

La ventaja de este enfoque es que siempre puede estar seguro de encontrar la secuencia de comandos de activación que pertenece al proyecto dentro.

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

Si decide ser un poco más organizada, se debe considerar poner todos los virtualenvs en una carpeta, y el nombre de cada uno de ellos después de que el proyecto que se está trabajando.

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

De esta manera siempre se puede empezar de nuevo con una nueva virtualenv cuando las cosas van mal, y los archivos del proyecto se mantengan seguros.

Otra ventaja es que varios de sus proyectos pueden usar el mismo virtualenv, por lo que no tiene que hacer la misma instalación una y otra vez si tiene muchas dependencias.

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

Para los usuarios que regularmente tienen que configurar y derribar virtualenvs que tendría sentido para mirar virtualenvwrapper.

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

Con virtualenvwrapper puede

* create and delete virtual environments 

* organize virtual environments in a central place 

* easily switch between environments 

Usted no más tiene que preocuparse de dónde están sus virtualenvs son cuando se trabaja en los proyectos de "foo" y "bar":

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

Este es la forma de empezar a trabajar en el proyecto "foo":

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

Luego de cambiar a proyectar "barra" es tan simple como esto:

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

Bastante limpio, ¿no es así?

Answer 3

Si le da a su proyecto un setup.py, pip puede importarlo directamente desde el control de la versión.

hacer algo como esto:

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

El -e pondrá el proyecto en myproject/src, pero vincularlo a myproject/lib/pythonX.X/site-packages/, por lo que cualquier cambio que haga ser recogido inmediatamente en módulos que importan desde su local de site-packages . El bit #egg le dice a pip qué nombre desea darle al paquete de huevos que crea para usted.

Si no se utiliza --no-site-packages, tenga cuidado al especificar que desea pip instalar en la virtualenv con la opción -E

Answer 4

Como los virtualenvs no son reubicables, en mi opinión, es una mala práctica colocar sus archivos de proyecto dentro de un directorio virtualenv. El virtualenv en sí es un artefacto de desarrollo/despliegue generado (algo así como un archivo .pyc), no parte del proyecto; debería ser fácil eliminarlo y volver a crearlo en cualquier momento, o crear uno nuevo en un nuevo servidor de despliegue, etc.

De hecho, muchas personas usan virtualenvwrapper, lo que elimina los virtualenvs reales de su conocimiento casi por completo, colocándolos todo junto en $ HOME/.virtualenvs por defecto.