Python: ¿cuál es la diferencia entre pythonbrew y virtualenv?
ruby rvm (5)
Dado que todas las respuestas anteriores son bastante antiguas, me gustaría resumir mis hallazgos aquí. Estaba intentando descubrir cómo funciona esto con Python después de venir de rvm / ruby y no pude encontrar una explicación clara en ningún lugar en línea.
Entonces tenemos las siguientes opciones en Macos:
Homebrew (solo MacOS)
... Puede instalar python y python3 . Se almacenarán en Homebrew''s Cellar y se vincularán simbólicamente desde /usr/local/bin . El python predeterminado instalado utilizando brew es 2.7.6 a partir de ahora.
Los paquetes instalados usando pip irán en la ubicación predeterminada (también tendrá pip3 enlace simbólico entre pip y pip3 ).
Pyenv (sucesor de Pythonbrew)
... Es una alternativa a Homebrew (en Macos) forma de instalar y mantener múltiples versiones de Python. Linux no tiene Homebrew así que Pyenv es una especie de versión especializada solo para Python. También construye Python desde la fuente.
Pyenv mantiene las instalaciones de python en ~/.pyenv/versions/ y permite cambiar rápidamente entre y usar los mismos nombres para los binarios ( python , pip , etc.). Utiliza binarios "shim" que son binarios falsos como python , pip , etc., que imitan a Python y en su lugar solo redirigen silenciosamente la ejecución a la versión actualmente activa.
Los paquetes instalados usando pip entrarán en la instalación de Python activa.
Por lo tanto, ninguno de esos métodos es realmente suficiente para mantener instalaciones de python separadas y conjuntos de versiones de paquetes (como rvm does with gemsets) por proyecto. Por lo tanto:
Virtualenv
... Es lo más parecido a rvm. Para citar esta publicación :
configura una copia limpia de Python en un nuevo directorio al copiar o vincular archivos de su instalación primaria de Python para crear nuevos directorios bin y lib
Entonces usa la copia actualmente activa de Python y la copia en un directorio separado. virtualenvwrapper agrega funcionalidad para administrar esos entornos y activarlos automáticamente usando cd al igual que rvm hace rvm .
Esto permite aislar la versión de Python y las bibliotecas instaladas utilizadas para cada proyecto. Sin embargo, no instala las versiones de python .
Por lo tanto, parece que la mayoría de la gente usa una combinación de pyenv + virtualenv o brew + virtualenv (por supuesto, el brew es específico de Macos). La primera parte se usa para instalar versiones de Python (si es necesario) y la segunda es clonarlas para diferentes proyectos y cambiar entre ellas.
PD: Estoy comenzando a resolverlo, corrígeme si algo está mal.
PPS: me parece que todo este negocio se puede mejorar combinando pyenv y virtualenv bajo un mismo techo ...
Soy nuevo en Python y estoy planeando aprender django. Tuve un poco de experiencia con ruby (no rieles) y estoy familiarizado con RVM sin embargo, no entiendo la diferencia entre pythonbrew y virtualenv . Sé que pythonbrew es una imitación de RVM pero pensé que virtualenv ya está haciendo lo que RVM hace (o viceversa que pythonbrew ya está haciendo lo que RVM hace). ¿Puede alguien explicar y quizás proporcionar algunos ejemplos / usos concretos para ayudarme a entenderlo? ¡Muchas gracias!
Por lo que vale, nunca antes había oído hablar de PythonBrew, pero sé (y amo) virtualenv.
Virtualenv se usa para crear entornos separados, en función de la instalación de Python que tenga en su máquina. Es decir, si tengo Python 2.7, puedo crear una cantidad de entornos de Python 2.7 aislados, pero no puedo crear ambientes de python2.6.
De acuerdo con this (que encontré a través de google) Pythonbrew parece estar enfocado en la instalación de otras versiones de Python. Así que supongo que usaría ''brew para instalar py2.6 y 2.7 y luego virtualenv para crear entornos para cada uno.
O, parece, ''brew puede crear los ambientes también, usando virtualenv.
¿Por qué un intérprete de Python diferente no es realmente un entorno aislado?
Cada instalación de Python tiene un conjunto de paquetes (creo que en ''site-packages''). Si instala un paquete nuevo, se agrega a este conjunto y está disponible para todo su código python.
Esto puede ser un problema si tiene un proyecto que compila en Django0.96 y desea iniciar un nuevo proyecto usando Django1.3. Si solo actualizas la versión de tu sistema de Django, eso también afectaría tu viejo proyecto.
Con virtualenvs puedes crear un entorno con Django1.3 y otro con Django0.96, ambos siendo python2.7. Si estaba bien con la ejecución de su proyecto anterior en python2.6 y el nuevo en python2.7 también podría hacerlo, pero ¿qué pasa con los próximos dos proyectos que utilizan versiones diffenret de Django-Trunk?
Python brew es para construir e instalar, tal vez como un buildbot. No estoy tan familiarizado. Virtualenv es principalmente para, cuando tienes diferentes versiones de python, o quieres probar algún paquete sin molestar a la versión del sistema.
Ok, esto revela algo
Cree entornos Python aislados (utiliza virtualenv ):
pythonbrew venv init
pythonbrew venv create proj
pythonbrew venv list
pythonbrew venv use proj
pythonbrew venv delete proj
Pythonbrew es similar al rvm de Ruby: es una función de shell que le permite:
- Cree una o más versiones autónomas completas de Python, cada una almacenada localmente en su directorio de inicio. Puedes construir múltiples versiones de Python de esta manera.
- Cambia entre las versiones de Python fácilmente.
Los Pythons que construyes están completamente aislados unos de otros, y de cualquier versión (es) de Python están instalados en todo el sistema.
Virtualenv es similar, pero no exactamente lo mismo. Crea un entorno virtual de Python que, conceptualmente, se asienta sobre una instalación de Python existente (por lo general, en todo el sistema, pero no siempre). Por defecto, en las plataformas Unix (y Mac), crea enlaces simbólicos a los diversos módulos de biblioteca Python, por lo que está literalmente compartiendo esos módulos con la implementación "real" de Python subyacente. Pero, virtualenv tiene su propio directorio "bin" y el directorio "site-packages". Cualquier cosa adicional que instale en el entorno virtual de Python solo está disponible en ese entorno.
Una ventaja de Pythonbrew es que los entornos de Python que crea son auténtica y completamente autónomos. No pueden contaminarse por nada que se arruine en una base subyacente de instalación de Python, porque no hay una instalación base subyacente. Esto no es verdad en ambientes virtualenv. Si creas un Python virtualenv, y luego de alguna manera arruinas la instancia base de Python que se encuentra arriba (por ejemplo, borrando accidentalmente parte del directorio "site" de Python de la base mientras estás conectado como root), arruinarás cualquier entorno virtualenv basado en ese Python, también.
Sin embargo, virtualenv tiene sus propias ventajas. Probablemente la mayor ventaja es que es liviano. Como Pythonbrew compila Python desde cero, para crear uno de sus entornos, la creación de un entorno Pythonbrew Python lleva algo de tiempo. En comparación, la creación de un entorno Virtualenv Python es realmente rápido.
De hecho, puede usarlos juntos. Aquí hay una situación en la que quizás quieras hacer eso.
- Su sistema base usa Python 2.6.
- Necesita instalar Python 2.7.
- Por alguna razón, no puede (o no quiere) instalar Python 2.7 en todo el sistema, lado a lado con Python 2.6.
En tal caso, podría usar Pythonbrew para instalar una base Python 2.7 en su directorio de inicio , donde no entre en conflicto con algo instalado en otro lugar. Luego, puede crear uno o más entornos virtualenv Python livianos que estén basados en su Pythonbrew 2.7 instalado. Por ejemplo, puede usar virtualenv para crear entornos de prueba de corta duración para Python 2.7 de esa manera.
Dudo que la mayoría de la gente realmente haga eso. (Yo no.) Pero no hay razón por la que no puedas.
"pythonbrew is a program to automate the building and installation
of Python in the users $HOME."
Por el contrario, virtualenv proporciona un entorno aislado para desarrollar un proyecto: mantiene todas las bibliotecas para ese proyecto en un solo lugar, y hace que sea mucho más fácil reubicar (y así desplegar) el proyecto.