¿Es malo tener mi directorio virtualenv dentro de mi repositorio git?

Solía hacer lo mismo hasta que comencé a usar bibliotecas que se compilan de manera diferente dependiendo del entorno, como PyCrypto. Mi PyCrypto mac no funcionaría en Cygwin no funcionaría en Ubuntu.

Administrar el repositorio se convierte en una pesadilla.

De cualquier manera me resultó más fácil administrar el archivo de requisitos de congelación y a de pip que tenerlo todo en git. También es más limpio, ya que puede evitar el spam de confirmación de miles de archivos a medida que se actualizan esas bibliotecas...

Almacenar el directorio virtualenv dentro de git, como has señalado, te permitirá desplegar toda la aplicación simplemente haciendo un clon de git (además de instalar y configurar Apache/mod_wsgi). Un problema potencialmente significativo con este enfoque es que en Linux la ruta completa se codifica en el activate de venv, django-admin.py, easy_install y scripts pip. Esto significa que su virtualenv no funcionará completamente si desea usar una ruta diferente, tal vez para ejecutar varios hosts virtuales en el mismo servidor. Creo que el sitio web puede funcionar con las rutas incorrectas en esos archivos, pero tendría problemas la próxima vez que intente ejecutar pip.

La solución, ya dada, es almacenar suficiente información en git para que durante el deploy puedas crear el virtualenv y hacer las instalaciones pip necesarias. Normalmente las personas ejecutan pip freeze para obtener la lista y luego la almacenan en un archivo llamado requirements.txt. Se puede cargar con pip install -r requirements.txt. RyanBrady ya mostró cómo puede encadenar las instrucciones deploy en una sola línea:

# before 15.1.0
virtualenv --no-site-packages --distribute .env &&\
    source .env/bin/activate &&\
    pip install -r requirements.txt

# after deprecation of some arguments in 15.1.0
virtualenv .env && source .env/bin/activate && pip install -r requirements.txt

Personalmente, acabo de poner estos en un script de shell que corro después de hacer el clon de git o git pull.

Almacenar el directorio virtualenv también hace que sea un poco más complicado manejar actualizaciones pip, ya que tendrá que agregar/eliminar manualmente y confirmar los archivos resultantes de la actualización. Con requisitos.archivo txt, usted acaba de cambiar las líneas apropiadas en los requisitos.txt y volver a ejecutar pip install -r requirements.txt. Como ya se ha señalado, esto también reduce "cometer spam".

Creo que uno de los principales problemas que se producen es que el virtualenv podría no ser utilizable por otras personas. La razón es que siempre usa rutas absolutas. Así que si virtualenv estaba por ejemplo en /home/lyle/myenv/ asumirá lo mismo para todas las demás personas que usan este repositorio (debe ser exactamente la misma ruta absoluta). No puedes presumir que las personas usan la misma estructura de directorios que tú.

La mejor práctica es que todo el mundo está estableciendo su propio entorno (ya sea con o sin virtualenv) e instalando bibliotecas allí. Eso también hace que el código sea más utilizable en diferentes plataformas (Linux / Windows / Mac), también porque virtualenv se instala diferente en cada una de ellas.

Si sabe en qué sistemas operativos se ejecutará su aplicación, crearía un virtualenv para cada sistema e incluirlo en mi repositorio. Luego haría que mi aplicación detectara en qué sistema se está ejecutando y usara el virtualenv correspondiente.

El sistema podría identificarse, por ejemplo, utilizando el módulo platform.

De hecho, esto es lo que hago con una aplicación interna que he escrito, y a la que puedo agregar rápidamente un nuevo sistema virtualenv en caso de que es necesario. De esta manera, no tengo que confiar en que pip podrá descargar con éxito el software que requiere mi aplicación. Tampoco tendré que preocuparme por la compilación de, por ejemplo, psycopg2 que uso.

Si no sabe en qué sistema operativo puede ejecutarse su aplicación, probablemente sea mejor usar pip freeze como se sugiere en otras respuestas aquí.

Si acabas de configurar development env, usa pip freeze file, caz que limpia el repositorio de git.

Luego, si está realizando una implementación de producción, verifique toda la carpeta venv. Eso hará que su implementación sea más reproducible, no necesitará esos paquetes libxxx-dev y evitará los problemas de Internet.

Así que hay dos repositorios. Uno para su código fuente principal, que incluye requisitos.txt. Y un repositorio env, que contiene toda la carpeta venv.

Utilizo lo que es básicamente La respuesta de David Sickmiller con un poco más de automatización. Creo un archivo (no ejecutable) en el nivel superior de mi proyecto llamado activate con el siguiente contenido:

[ -n "$BASH_SOURCE" ] \
    || { echo 1>&2 "source (.) this with Bash."; exit 2; }
(
    cd "$(dirname "$BASH_SOURCE")"
    [ -d .build/virtualenv ] || {
        virtualenv .build/virtualenv
        . .build/virtualenv/bin/activate
        pip install -r requirements.txt
    }
)
. "$(dirname "$BASH_SOURCE")/.build/virtualenv/bin/activate"

(Según la respuesta de David, esto asume que estás haciendo un pip freeze > requirements.txt para mantener tu lista de requisitos actualizada.)

Esto se puede obtener de cualquier directorio de trabajo actual y se activará correctamente, primero configurando el entorno virtual si es necesario. Mi prueba de nivel superior por lo general, el script tiene código en estas líneas para que pueda ejecutarse sin que el desarrollador tenga que activarlo primero:

cd "$(dirname "$0")"
[[ $VIRTUAL_ENV = $(pwd -P) ]] || . activate