python - tutorial - Django y VirtualEnv Desarrollo/Mejores prácticas de implementación

virtualenv python 3

Question

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

• Más específicamente, ¿cómo puede mantener la producción virtualenv sincronizada correctamente con su máquina de desarrollo?

Yo uso git para scm pero no tengo mi virtualenv dentro del repositorio de git - debería, o es mejor usar el congelamiento de pip y luego volver a crear el ambiente en el servidor usando la salida de congelación? (Si hace esto, ¿podría describir los pasos? Estoy encontrando muy poca documentación buena sobre el proceso de descongelación, ¿es posible algo así como pip install -r freeze_output.txt ?)

Answer 1

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

1. En nuestro árbol fuente, 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. Fabric encontrará el SHA para lo que estamos implementando con git log -1 --format=format:%h TREEISH . Eso nos da SHA_OF_THE_RELEASE
4. Fabric 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. El script de Fabric buscará en un directorio donde nuestros virtualenvs estén almacenados en los host remotos.
   1. Si no hay un directorio llamado 1d02afc , se 1d02afc un nuevo virtualenv y se configura con pip install -E /path/to/venv/1d02afc -r /path/to/requirements.txt
   2. Si hay una path/to/venv/1d02afc , no se hace nada

La pequeña parte mágica de esto es pasar cualquier árbol que quieras maquillar, 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

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

que espera que el directorio se llame ''requisitos'' que se ve más o menos así: http://github.com/ccnmtl/ccnmtldjango/tree/master/ccnmtldjango/template/requirements/

Hay una apps.txt, una libs.txt (que incluye apps.txt, solo me gusta mantener separadas las aplicaciones django de otros módulos python) y un directorio src que contiene los archivos tar actuales.

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 adhiera 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) está predeterminada en Python 2.6 si no tiene cuidado)