Django y Desarrollo virtualenv/Mejores prácticas de implementación

Question

Simplemente curioso cómo las personas están implementando sus proyectos de Django en combinación con virtualenv

• Más específicamente, ¿cómo se mantiene de sus virtualenv producción sincronizada correctamente con el equipo de desarrollo?

usar git para SMC, pero no tengo a mi virtualenv dentro del repositorio git - ¿Debo, o es mejor utilizar la congelación de pepita y volver a crear el entorno en el servidor utilizando la salida de congelación ? (Si lo hace, podría describir los pasos - estoy encontrando muy poca buena documentación sobre el proceso de descongelación - es algo así como pip install -r freeze_output.txt posible?)

Answer 1

Acabo de poner algo así en el trabajo usando pip, Fabric y git. El flujo es básicamente como este, y toma prestado de this script:

1. En nuestro árbol de fuentes, mantenemos un archivo requirements.txt. Mantendremos esto de forma manual.
2. Cuando hacemos una nueva versión, la secuencia de comandos Fabric crea un archivo basado en cualquier treeish que lo pasemos.
3. La tela encontrará el SHA para lo que estamos implementando con git log -1 --format=format:%h TREEISH. Eso nos da SHA_OF_THE_RELEASE
4. La tela recibirá el último SHA para nuestro archivo de requisitos con git log -1 --format=format:%h SHA_OF_THE_RELEASE requirements.txt. Esto escupe la versión corta del hash, como 1d02afc que es el SHA para ese archivo para esta versión en particular.
5. La secuencia de comandos Fabric buscará en un directorio donde se almacenan nuestros archivos virtuales en los hosts remotos.
   1. Si no hay un directorio llamado 1d02afc, se crea un nuevo virtualenv y configuración con pip install -E /path/to/venv/1d02afc -r /path/to/requirements.txt
   2. Si hay es una ya existente path/to/venv/1d02afc, no se hace nada

La pequeña magia parte de esto es pasar cualquier árbol que quieras hacer, y hacer que haga el embalaje (desde Tela). Al usar git archive my-branch, git archive 1d02afc o lo que sea, estoy seguro de que obtendré los paquetes correctos instalados en mis máquinas remotas.

Fui por esta ruta ya que realmente no quería tener virtuenvs extra flotando si los paquetes no habían cambiado entre lanzamiento. Tampoco me gusta la idea de tener los paquetes reales de los que dependo en mi propio árbol fuente.

Answer 2

Yo uso este bootstrap.py: http://github.com/ccnmtl/ccnmtldjango/blob/master/ccnmtldjango/template/bootstrap.py

la que espera son directorios llamados 'requisitos' que se parecen a esto: http://github.com/ccnmtl/ccnmtldjango/tree/master/ccnmtldjango/template/requirements/

Hay una apps.txt, una libs.txt (que incluye la aplicación.txt, solo me gusta mantener las aplicaciones django separadas de otros módulos de python) y una src directorio que contiene los archivos de bolas reales.

Cuando se ejecuta ./bootstrap.py, crea el virtualenv (borrando uno anterior si existe) e instala todo desde requirements/apps.txt en él. No instalo nada en el virtualenv de lo contrario. Si quiero incluir una nueva biblioteca, pongo el archivo tar en requirements/src /, agrego una línea a uno de los archivos de texto y vuelvo a ejecutar ./bootstrap.py.

bootstrap.py y los requisitos se comprueban en el control de versiones (también una copia de pip.py, así que ni siquiera tengo que tenerlo instalado en todo el sistema). El virtualenv en sí mismo no lo es. Los scripts que tengo que enviar a producción ejecutan ./bootstrap.py en el servidor de producción cada vez que lo presiono. (bootstrap.py también hace todo lo posible para asegurarse de que se adhiere a Python 2.5 ya que eso es lo que tenemos en los servidores de producción (Ubuntu Hardy) y mi máquina de desarrollo (Ubuntu Karmic) se predetermina a Python 2.6 si no tiene cuidado)