Virtualenv y control de versión de código fuente

3 minutos de lectura

avatar de usuario
Martín

Recientemente comencé un proyecto de Django y rápidamente me di cuenta de que virtualenv será realmente útil por muchas razones. Configuré virtualenv y mi proyecto, pero ahora me pregunto qué archivo debo agregar a mi control de fuente (en mi caso, Mercurial). ¿Debo agregar todos los archivos en la carpeta venv? ¿Cómo me aseguro de que un colega pueda clonar y comenzar a trabajar de inmediato sin tener que configurar el env nuevamente?

  • No recomendaría poner el virtualenv bajo control de fuente: no será portátil en versiones de Python, sistemas operativos o plataformas de 32/64 bits. En cambio, solo usa ~/path/to/virtualenv/bin/pip freeze > ~/path/to/repo/requirements.txt. Otros desarrolladores necesitarán configurar su propio virtualenv, pero son literalmente dos comandos: virtualenv ~/path/to/env, ~/path/to/env/bin/pip install -r ~/path/to/requirements.txt.

    – AdamKG

    6 de marzo de 2012 a las 15:17

  • Estimado googler, consulte también: stackoverflow.com/a/6012590/82216

    usuario82216

    7 mayo 2013 a las 15:33

Usted genera un archivo de “requisitos” (generalmente requirements.txt) que te comprometes con tu proyecto:

pip freeze > requirements.txt

Luego, cada desarrollador configurará su propio virtualenv y ejecutará:

pip install -r requirements.txt

avatar de usuario
Arturo Neves

¡Todas estas molestias ambientales son algo comunes cuando se está desarrollando en python/django! ¡Pasé por todos estos problemas y probé algunas soluciones! Cosas que he probado:

  1. Proyecto que se ejecuta localmente
  2. Proyecto ejecutándose en virtualenv
  3. Proyecto ejecutándose en una VM
  4. Proyecto ejecutándose en una VM, usando vagabundo

¡La mejor solución que encontré fue la #4! porque en la empresa en la que trabajaba, cada persona en el equipo tiene un sistema operativo diferente, todo tipo de Windows, Mac y Linux, ¡y para instalar todas las dependencias para cada entorno lleva tiempo! Así que decidimos probar virtualenv, ¡que es realmente bueno! pero aún así cada persona tiene que configurar su propio entorno. ¡El problema en virtualenv es que todas las fuentes de python están dentro del entorno que creas! ¡Así que no empujaría esos archivos a un control de versión de origen! La mejor solución fue la #4, porque eso era exactamente lo que necesitaba, Vagrant usa Chef para configurar su entorno, por lo que solo tiene que escribir algunas recetas y dejar que Vagrant las ejecute por usted. Luego, envíe esas recetas a SCM, luego, cuando la siguiente persona obtenga los archivos de SCM y vuelva a cargar la VM, ¡todas las dependencias se instalarán automáticamente!

Tengo una publicación de blog que explica más sobre el tema, así como también he creado un proyecto Django Blank en github para que pueda hacer que tenga un punto de inicio de su proyecto usando vagrant.

http://arthurnn.com/blog/2011/11/25/inicio-rápido-fácil-django/ (el enlace ya no está activo, por lo que está vinculado a Wayback Machine)

EDITAR

La solución de Chris Pratt también es buena, sin embargo, algunas bibliotecas no son tan fáciles de instalar en todos los sistemas operativos, por ejemplo, muchas personas en Mac tienen problemas cuando quieren instalar MySQLdb-python. que es una biblioteca muy común, pero si todos en su equipo tienen que pasar tiempo resolviendo estos problemas, ¡no es bueno en absoluto!

  • MySQLdb-python Esta es una muy buena razón para usar un entorno completo, pero ¿no se puede lograr esto también con pip/requirements.txt?

    – kconstruye

    27 de agosto de 2014 a las 20:18

¿Ha sido útil esta solución?