python - activate - virtualenv ubuntu

¿Cuáles son los beneficios de pip y virtualenv?

Question

Entonces, todos me dicen que use pip y virtualenv, pero nadie puede explicarme cómo es mejor que mi enfoque actual. La razón principal para que la gente use pip y virtualenv parece ser que todos los demás lo están usando ...

Estoy seguro de que hay muy buenas razones para usar PIP y virtualenv pero no he podido encontrarlos con Google. Espero que alguien de la comunidad stackoverflow pueda explicarmelas.

Así es como actualmente organizo mis proyectos de Django:

site/src/ : contains all python-only dependencies of my project
site/lib/ : contains symlinks to the python packages
site/[projectname]/ : contains all my project specific code

Toda la carpeta del sitio es verificar en mi repositorio (sí, incluidas todas las dependencias solo de Python como django).

Todas las dependencias que no son de solo pitón (PIL, psycopg2, ...) se documentan en un archivo README y se instalan en el nivel del sistema (apt-get install ....)

Por ejemplo, digamos que tengo un nombre de proyecto "projectfoo" que depende de django-1.2.3, pygeoip-0.1.3 y psycopg2 tendré:

/usr/lib/python2.5/site-packages/psycopg2
~/projects/foo/site : checkout of my repository
~/projects/foo/site/src/django-1.2.3
~/projects/foo/site/src/pygeoip-0.1.3
~/projects/foo/site/lib/django -> symlink to ../src/django-1.2.3/django
~/projects/foo/site/lib/pygeoip -> symlink to ../src/pygeoip-0.1.3/pygeoip
~/projects/foo/site/projectfoo/

Ahora, ¿cómo se compara esto con PIP / virtualenv en la práctica?

Implementar el proyecto con mi enfoque actual :

svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site

Despliegue con PIP / virtualenv :

wget https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/projectfoo-requirements.txt
pip install -U -E projectfoo-venv -r projectfoo-requirements.txt

Trabajando en un proyecto con mi enfoque actual :

cd ~/projects/foo/site/projectfoo
export PYTHONPATH=.:..:../lib
./manage.py runserver 0:8000

Trabajando en un proyecto con PIP / virtualenv :

workon projectfoo
cd path/to/project
./manage.py runserver 0:8000

Tratando con dependencias que no son solo python :

las dependencias que no son solo python se manejarían de la misma manera, no hay manera de que vaya a usar la --no-site-packages de virtualenv e instalar un compilador y todas las dependencias de compilación en mis servidores, no lo hago Creo que alguien lo está haciendo de todos modos.

Actualización de una dependencia de solo python con mi enfoque actual :

Compruebo / descomprimo la nueva versión en src, elimino la anterior de src, actualizo el enlace simbólico en lib y commit. Ahora todos los demás que trabajen en el proyecto recibirán la actualización en su próxima actualización de svn up o git pull . Una cosa que no es agradable es que la carpeta antigua en src se mantendrá si contiene algún archivo pyc, esto se puede evitar fácilmente eliminando todos los pyc antes de actualizar su copia local.

Actualizando una dependencia de solo python con PIP / virtualenv :

Usted compromete una nueva versión del archivo de requisitos, con suerte todos los que trabajan en el proyecto notan la nueva versión cuando actualizan su copia local y luego ejecutan pip install -E projectfoo-venv -r requirements.txt .

Editar : Elimino el uso de -U con pip, esto no es necesario con pip 8.2

Editar : La única ventaja en pip / virtualenv sobre mi enfoque actual parece ser cuando trabajas en diferentes proyectos que requieren diferentes versiones de python. Pero en mi experiencia, cuando necesitas diferentes versiones de python, también necesitas diferentes versiones de otras bibliotecas del sistema (PIL, psycopg2, ...) y virtualenv no ayuda con eso (excepto si estás lo suficientemente loco como para usar el - opción no-site-package, e incluso entonces está incompleto). La única solución que se me ocurre para esa situación es usar diferentes máquinas virtuales.

Entonces, ¿qué me estoy perdiendo? ¿Puede alguien señalarme un caso de uso en el que PIP o virtualenv serían mejores que lo que estoy haciendo?

Answer 1

Despliegue con PIP / virtualenv:

De acuerdo a ti:

wget https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/projectfoo-requirements.txt
pip install -U -E projectfoo-venv -r projectfoo-requirements.txt

Lo que hago: también "congelo" paquetes pero lo hago con pip y virtualenv y virtualenv todo el proyecto; incluyendo los paquetes de Python. Entonces mi implementación es exactamente como la tuya:

svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site

Trabajando en un proyecto con PIP / virtualenv:

De acuerdo a ti:

workon projectfoo
cd path/to/project
./manage.py runserver 0:8000

Lo que hago: agregue un gancho postactivate como este:

$ cat bin/postactivate
cd $VIRTUAL_ENV
./manage.py runserver 0:8000
$

Y ahora, para cambiar al proyecto:

workon projectfoo

Answer 2

virtualenv realmente brilla cuando tienes varios proyectos, y no quiere que todos compartan la misma instalación de Python. Por ejemplo, podría tener dos proyectos con requisitos conflictivos.

Answer 3

"Todas las dependencias que no son solo de pitón (PIL, psycopg2, ...) están documentadas en un archivo README e instaladas a nivel del sistema (apt-get install ....)"

Entonces no puede tener dependencias diferentes para diferentes proyectos, y no versiones diferentes de estas dependencias para diferentes proyectos.

Un efecto de esto es que las instalaciones locales no reflejan con precisión las máquinas de producción, por lo que puede tener problemas para reproducir errores de producción, por ejemplo.

Y si instala las herramientas del sistema que necesitan una versión, se ve obligado a utilizar esa misma versión en todas partes, lo que puede interrumpir sus proyectos.

Además, los módulos de recuperación deben hacerse en el nivel python del sistema. Virtualenv significa que puede configurar una instalación de Python para probar cosas sin contaminar la instalación del sistema.

Definitivamente recomendaría tener una python separada para sus proyectos, y usar algo que aísla incluso a Python de los proyectos, como virtualenv o zc.buildout.

PIP es solo una forma más fácil de instalar módulos, que también te ayuda a desinstalarlos.

"No hay manera de que use la opción --no-site-packages de virtualenv e instale un compilador y todas las dependencias de compilación en mis servidores, no creo que nadie lo esté haciendo de todos modos".

No, uso zc.buildout, pero equivale a más o menos lo mismo, pero menos trabajo. ;)

Answer 4

Sigo el método que has sugerido sin pip / virtualenv para mis proyectos habituales. Esto me permite poner los paquetes en un directorio específico.

+ext
|
|------python packages
+source
|
|------ project code and packages

Y generalmente en el script de inicio actualizo PYTHONPATH

export PYTHONPATH="";
export PYTHONPATH="${PYTHONPATH}:${workingdir}/path/to/ext";

Esto tiene la ventaja de mantener el proyecto y las dependencias autónomos. Me hago eco, tus pensamientos aquí.

Como sea, encuentro el uso de virtualenv, cuando

1. Tengo que experimentar con something new .
2. Aún mejor cuando quiero usar two different versions of package y compararlas.
3. Otro uso es donde guardo different related packages that can be used across projects .

Ej: Documentación : algunos paquetes clave que he instalado incluyen sphinx, pygraphwiz, nterworkX y algunos paquetes de visualización más. Lo uso en todos los proyectos y también lo mantengo fuera de la instalación a nivel del sistema para mantenerlo sin contaminación.

También me gustaría que pagues: Yema. Lo encuentro agradable en combinación de pip / virtualenv.

Puede listar paquetes

yolk -l
Jinja2 - 2.5.5 - active
Markdown - 2.0.3 - active
Pycco - 0.1.2 - active
......

Y mira las actualizaciones de pypi.

yolk --show-updates
Pycco 0.1.2 (0.2.0)
Sphinx 1.0.4 (1.0.5)
pip 0.8.1 (0.8.2)