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


107

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

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

Una vez creado este entorno, ¿dónde colocaría uno el suyo?

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

en relación con los virtualenvdirectorios?

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


8
@jkp: No estoy de acuerdo. La forma en que diseña una aplicación de Python es un asunto diferente de cómo ubica esa aplicación dentro de un virtualenv para fines de desarrollo. Está relacionado, pero no es lo mismo. Por favor no cierre como duplicado.
jcdyer

Respuestas:


90

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

Por ejemplo, puede tener un proyecto en el que tenga varias aplicaciones que utilicen el mismo virtualenv. O puede estar probando una aplicación con un virtualenv que luego se implementará con un sistema Python. O puede estar empaquetando 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 lo bueno virtualenves que admite muchos casos de uso diferentes: no es necesario que haya una forma correcta.


8
Convenido. Uso virtualenv para todo lo que hago, y nunca coloco archivos dentro del directorio virtualenv. Virtualenv no necesita tener ningún impacto en la estructura de su proyecto; simplemente active virtualenv (o use su bin / python) y trabaje en sus archivos donde los tenga de todos modos.
Carl Meyer

También estoy totalmente de acuerdo. La única vez que nunca toco todos los archivos dentro de mi virtualenv (utilización Me virtualenvwrapper) es cuando quiero editar el postactivatey postdeactivateganchos.
Thane Brimhall

La pregunta estaría mejor atendida con ejemplos prácticos y concretos de diferentes opciones, incluidas las compensaciones, como se ve en otras respuestas de esta pregunta.
andyfeller

2
Es más limpio mantener su proyecto separado del virtualenvdirectorio, pero compararlo virtualenvcon el sistema python no es útil, porque el propósito de virtualenves reparar dependencias rotas y aislar proyectos para que puedan usar diferentes versiones de paquetes e incluso versiones de Python (me doy cuenta de que esto fue escrito antes -python3). Permitir que las aplicaciones compartan un virtualenvuso virtualenvcomo si fuera python del sistema, dejando a las aplicaciones vulnerables a los mismos problemas que virtualenv está diseñado para resolver. There should be one obvious way to do it; lógicamente debería ser 1: 1
Davos

@Ned: Tratando de adquirir algunas mejores prácticas, pero aún no está claro: si tiene docenas de proyectos, cada uno con su propio virtualenv, ¿cómo puede realizar un seguimiento de qué proyecto se utiliza con qué virtualenv? ¿Agregar pequeños scripts de shell en la raíz de cada carpeta con el nombre del virtualenv con el que lo usa?
ccpizza

57

Si solo tiene unos pocos proyectos de vez en cuando, nada le impide crear un nuevo virtualenv para cada uno y poner sus paquetes dentro:

/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 el script de activación que pertenece al proyecto dentro.

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

Si decides ser un poco más organizado, deberías considerar poner todos tus virtualenvs en una carpeta y nombrar a cada uno de ellos según el proyecto en el que estás 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 puede comenzar de nuevo con un nuevo virtualenv cuando las cosas vayan mal y los archivos de su proyecto se mantienen 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 eliminar virtualenv, 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 empiezas a trabajar en el proyecto "foo":

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

Entonces, cambiar a la "barra" del proyecto es tan simple como esto:

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

Bastante ordenado, ¿no?


Estoy totalmente de acuerdo con esta respuesta sobre el uso virtualenvwrapper. Abstrae perfectamente el virtualenv sin dejar de ofrecerle todos los beneficios.
Thane Brimhall

5
Pero no estoy de acuerdo en poner su código NUNCA dentro del entorno virtual. Si lo desea "cerca" del proyecto en el sistema de archivos, coloque un venv/directorio en el mismo nivel que el del proyecto BASE_DIR.
Rob Grant

30

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

De hecho, muchas personas usan virtualenvwrapper , que elimina los virtualenvs reales de su conciencia casi por completo, colocándolos todos uno al lado del otro en $ HOME / .virtualenvs por defecto.


Totalmente de acuerdo en que es una mala práctica, es bueno señalar que debería ser fácil de volar y recrear, especialmente para probar implementaciones y eliminar paquetes de requisitos innecesarios. Solo quiero agregar que virtualenv es posible reubicarse usando, por ejemplo, virtualenv --relocatable myvenvconsulte stackoverflow.com/a/6628642/1335793 solo porque puede no significa que deba hacerlo.
Davos

2

Si le da a su 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 -ecolocará el proyecto myproject/src, pero lo vinculará myproject/lib/pythonX.X/site-packages/, por lo que cualquier cambio que realice se recogerá inmediatamente en los módulos que lo importan desde su local site-packages. El #eggbit le dice a pip qué nombre desea darle al paquete de huevos que crea para usted.

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.