python - activate - virtualenvwrapper

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

Question

¿Qué tipo de estructura de directorios se debe seguir cuando se usa virtualenv ? Por ejemplo, si estuviera construyendo una aplicación WSGI y creara un virtualenv llamado foobar , comenzaría con una estructura de directorios como:

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

Una vez que se crea este entorno, ¿dónde colocarían uno los suyos?

• 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 queso?

en relación con los directorios virtualenv ?

(Supongamos que ya sé a dónde deberían ir los directorios virtualenv mismos ).

Answer 1

Debido a que los recursos virtuales 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 host de implementación, etc.

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

Answer 2

Si le das a tu proyecto un setup.py , pip puede importarlo directamente desde el control de versiones.

Haz 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 ubicará el proyecto en myproject/src , pero lo vinculará a myproject/lib/pythonX.X/site-packages/ , de modo que cualquier cambio que realice se myproject/lib/pythonX.X/site-packages/ inmediatamente en los módulos que lo importen de sus site-packages locales site-packages . El bit #egg le dice a pip qué nombre quieres darle al paquete de huevos que crea para ti.

Si no usa --no-site-packages , tenga cuidado de especificar que desea que pip se instale en el virtualenv con la opción -E

Answer 3

Si solo tiene algunos proyectos de vez en cuando, nada le impide crear un nuevo virtualenv para cada uno, y poner sus 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 organizarse un poco más, debería considerar poner todos sus virtualenvs en una sola carpeta y nombrarlos después del proyecto en el que 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 forma, siempre puede volver a comenzar con un nuevo virtualenv cuando las cosas van mal y los archivos de su proyecto permanecen seguros.

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

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

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

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

Con virtualenvwrapper puedes

* create and delete virtual environments
* organize virtual environments in a central place
* easily switch between environments

Ya no tienes que preocuparte por dónde están tus virtualenvs cuando trabajas en los proyectos "foo" y "bar":

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

Así es como comienzas a trabajar en el proyecto "foo":

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

Entonces cambiar al proyecto "bar" es tan simple como esto:

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

Bastante limpio, ¿no?

Answer 4

virtualenv proporciona una instancia de intérprete python, 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, puede tener un proyecto donde tenga múltiples aplicaciones usando 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.

Entonces, en general, no creo que haya una respuesta correcta a la pregunta. Y, algo bueno de virtualenv es que admite muchos casos de uso diferentes: no es necesario que haya una manera correcta.