Python 3.3 incluye en su biblioteca estándar el nuevo paquete venv . ¿Qué hace y en qué se diferencia de todos los demás paquetes que parecen coincidir con la expresión regular (py)?(v|virtual|pip)?env ?
Esta es mi recomendación personal para principiantes: comience por aprender virtualenv y pip , herramientas que funcionan con Python 2 y 3 y en una variedad de situaciones, y elija otras herramientas una vez que comience a necesitarlas.
Ahora pasemos a la respuesta a la pregunta: ¿cuál es la diferencia entre estas cosas con nombres similares: venv, virtualenv, etc.?
virtualenv es una herramienta muy popular que crea entornos de Python aislados para bibliotecas de Python. Si no está familiarizado con esta herramienta, le recomiendo que la aprenda, ya que es una herramienta muy útil.
Funciona instalando un montón de archivos en un directorio (p. ej.: env/ ) y luego modificando la variable de entorno PATH para prefijarla con un directorio bin personalizado (p. ej.: env/bin/ ). Una copia exacta del binario python o python3 se coloca en este directorio, pero Python está programado para buscar bibliotecas relativas a su ruta primero, en el directorio de entorno. No es parte de la biblioteca estándar de Python, pero está oficialmente bendecida por PyPA (Python Packaging Authority). Una vez activado, puede instalar paquetes en el entorno virtual usando pip .
pyenv se usa para aislar versiones de Python. Por ejemplo, es posible que desee probar su código con Python 2.7, 3.6, 3.7 y 3.8, por lo que necesitará una forma de alternar entre ellos. Una vez activado, antepone la variable de entorno PATH con ~/.pyenv/shims , donde hay archivos especiales que coinciden con los comandos de Python ( python , pip ). Estas no son copias de los comandos enviados por Python; son scripts especiales que deciden sobre la marcha qué versión de Python ejecutar en función de la variable de entorno PYENV_VERSION , el archivo .python-version o el archivo ~/.pyenv/version . pyenv también facilita el proceso de descarga e instalación de múltiples versiones de Python, usando el comando pyenv install .
pyenv-virtualenv es un complemento para pyenv del mismo autor que pyenv , que le permite usar pyenv y virtualenv al mismo tiempo de manera conveniente. Sin embargo, si usa Python 3.3 o posterior, pyenv-virtualenv intentará ejecutar python -m venv si está disponible, en lugar de virtualenv . Puede usar virtualenv y pyenv juntos sin pyenv-virtualenv , si no desea las características de conveniencia.
virtualenvwrapper es un conjunto de extensiones para virtualenv (ver docs ). Le brinda comandos como mkvirtualenv , lssitepackages y especialmente workon para cambiar entre diferentes directorios virtualenv . Esta herramienta es especialmente útil si desea múltiples directorios virtualenv .
pyenv-virtualenvwrapper es un complemento para pyenv del mismo autor que pyenv , para integrar convenientemente virtualenvwrapper en pyenv .
pipenv tiene como objetivo combinar Pipfile , pip y virtualenv en un solo comando en la línea de comandos. El directorio virtualenv generalmente se coloca en ~/.local/share/virtualenvs/XXX , siendo XXX un hash de la ruta del directorio del proyecto. Esto es diferente de virtualenv , donde el directorio suele estar en el directorio de trabajo actual. pipenv está diseñado para usarse al desarrollar aplicaciones de Python (a diferencia de las bibliotecas). Hay alternativas a pipenv , como la poetry , que no mencionaré aquí ya que esta pregunta es solo sobre los paquetes que tienen nombres similares.
pyvenv (que no debe confundirse con pyenv en la sección anterior) es un script enviado con Python 3 pero obsoleto en Python 3.6 porque tenía problemas (sin mencionar el nombre confuso). En Python 3.6+, el equivalente exacto es python3 -m venv .
venv es un paquete enviado con Python 3, que puede ejecutar usando python3 -m venv (aunque por alguna razón algunas distribuciones lo separan en un paquete de distribución separado, como python3-venv en Ubuntu/Debian). Tiene el mismo propósito que virtualenv , pero solo tiene un subconjunto de sus características ( ver una comparación aquí ). virtualenv sigue siendo más popular que venv , especialmente porque el primero es compatible con Python 2 y 3.
Simplemente evitaría el uso de virtualenv después de Python3.3+ y, en su lugar, usaría la biblioteca estándar enviada venv . Para crear un nuevo entorno virtual, escribiría:
$ python3 -m venv <MYVENV> virtualenv intenta copiar el binario de Python en el directorio bin del entorno virtual. Sin embargo, no actualiza los enlaces de archivos de la biblioteca incrustados en ese binario, por lo que si compila Python desde la fuente en un directorio que no sea del sistema con nombres de ruta relativos, el binario de Python se rompe. Dado que así es como se hace una copia distribuible de Python, es un gran defecto. Por cierto, para inspeccionar los enlaces de archivos de biblioteca incrustados en OS X, use otool . Por ejemplo, desde su entorno virtual, escriba:
$ otool -L bin/python python: @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0) En consecuencia, evitaría virtualenvwrapper y pipenv . pyvenv está en desuso. pyenv parece usarse a menudo donde se usa virtualenv , pero también me mantendría alejado de él, ya que creo que venv también hace lo que pyenv está diseñado.
venv crea entornos virtuales en el shell que son nuevos y están protegidos , con bibliotecas instalables por el usuario y es seguro para varias Python .
Nuevo : debido a que los entornos virtuales solo comienzan con las bibliotecas estándar que se envían con python, debe instalar cualquier otra biblioteca nuevamente con pip install mientras el entorno virtual está activo.
Sandboxed : porque ninguna de estas nuevas instalaciones de biblioteca es visible fuera del entorno virtual, por lo que puede eliminar todo el entorno y comenzar de nuevo sin preocuparse por el impacto en su instalación base de Python.
Bibliotecas instalables por el usuario : debido a que la carpeta de destino del entorno virtual se crea sin sudo en algún directorio que ya posee, por lo que no necesitará permisos de sudo para instalar bibliotecas en él.
Seguro multi-python : porque cuando se activan los entornos virtuales, el shell solo ve la versión de python (3.4, 3.5, etc.) que se usó para construir ese entorno virtual.
pyenv es similar a venv en que le permite administrar múltiples entornos de python. Sin embargo, con pyenv no puede revertir convenientemente las instalaciones de la biblioteca a algún estado de inicio y es probable que necesite privilegios de admin en algún momento para actualizar las bibliotecas. Así que creo que también es mejor usar venv .
En los últimos años, encontré muchos problemas en los sistemas de compilación (paquetes de Emacs, creadores de aplicaciones independientes de Python, instaladores...) que finalmente se reducen a problemas con virtualenv . Creo que Python será una mejor plataforma cuando eliminemos esta opción adicional y solo usemos venv .
EDITAR: Tweet de la BDFL,
Uso venv (en stdlib) y un montón de alias de shell para cambiar rápidamente.
– Guido van Rossum (@gvanrossum) 22 de octubre de 2020
Añadido debajo del párrafo " Conclusión "
Bajé por el agujero del conejo de pipenv ( de hecho, es un agujero profundo y oscuro... ) y dado que la última respuesta es hace más de 2 años , sentí que era útil actualizar la discusión con los últimos desarrollos sobre el tema de los sobres virtuales de Python He encontrado.
Esta respuesta NO se trata de continuar el debate furioso sobre los méritos de pipenv versus venv como soluciones envolventes; no apoyo ninguna de las dos . Se trata de que PyPA respalde estándares en conflicto y cómo el desarrollo futuro de virtualenv promete negar la elección entre ellos. Me enfoqué en estas dos herramientas precisamente porque son las ungidas por PyPA .
Como señala el OP, venv es una herramienta para virtualizar entornos. NO es una solución de terceros, sino una herramienta nativa. PyPA respalda a venv para la creación de ENVOLVENTES VIRTUALES : " Modificado en la versión 3.5: ahora se recomienda el uso de venv para la creación de entornos virtuales ".
pipenv , como venv , se puede usar para crear sobres virtuales pero, además, incluye la administración de paquetes y la funcionalidad de verificación de vulnerabilidades . En lugar de usar requirements.txt , pipenv ofrece administración de paquetes a través de Pipfile . Como PyPA respalda a pipenv para la GESTIÓN DE PAQUETES , eso parecería implicar que pipfile suplantará a requirements.txt .
SIN EMBARGO : pipenv usa virtualenv como su herramienta para crear sobres virtuales, NO venv , que está respaldado por PyPA como la herramienta de referencia para crear sobres virtuales.
Entonces, si decidirse por una solución de sobre virtual no fuera lo suficientemente difícil, ahora PyPA respalda dos herramientas diferentes que utilizan diferentes soluciones de sobre virtual. El furioso debate de Github sobre venv vs virtualenv que destaca este conflicto se puede encontrar aquí .
El debate de Github al que se hace referencia en el enlace anterior ha dirigido el desarrollo de virtualenv en la dirección de acomodar venv en futuras versiones :
prefiera venv incorporado: si el python de destino tiene venv, crearemos el entorno usando eso (y luego realizaremos operaciones posteriores para facilitar otras garantías que ofrecemos)
Por lo tanto, parece que habrá cierta convergencia futura entre las dos soluciones de envolvente virtual rivales, pero a partir de ahora, pipenv , que usa virtualenv , difiere sustancialmente de venv .
Dados los problemas que resuelve pipenv y el hecho de que PyPA ha dado su bendición, parece tener un futuro brillante. Y si virtualenv cumple con los objetivos de desarrollo propuestos, elegir una solución de envolvente virtual ya no debería ser un caso de pipenv O venv .
Una crítica repetida a Pipenv que vi al producir este análisis fue que no se mantuvo activamente. De hecho, ¿cuál es el sentido de utilizar una solución cuyo futuro podría verse cuestionado debido a la falta de desarrollo continuo? Después de un período de sequía de aproximadamente 18 meses, Pipenv se está desarrollando nuevamente de manera activa. De hecho, desde entonces se han publicado actualizaciones importantes y sustanciales.
Actualización de enero de 2020
@Flimm ha explicado muy bien todas las diferencias. En general, queremos saber la diferencia entre todas las herramientas porque queremos decidir qué es lo mejor para nosotros. Entonces, la siguiente pregunta sería: ¿cuál usar? Le sugiero que elija una de las dos formas oficiales de administrar entornos virtuales:
pipenv quiere combinar todo, además de lo anterior, instala "requisitos" (en el entorno virtual activo o crea uno propio si no hay ninguno activo)
Así que tal vez estés contento solo con pipenv.
Pero uso: pyenv + pyenv-virtualenvwrapper, + pipenv (pipenv solo para requisitos de instalación).
En Debian:
apt install libffi-dev
instale pyenv basado en https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/ , pero...
.. pero en lugar de pyenv-virtualenv, instale pyenv-virtualenvwrapper (que puede ser una biblioteca independiente o un complemento de pyenv, aquí la segunda opción):
$ pyenv install 3.9.0 $ git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(pyenv root)/plugins/pyenv-virtualenvwrapper # inside ~/.bashrc add: # export $VIRTUALENVWRAPPER_PYTHON="/usr/bin/python3" $ source ~/.bashrc $ pyenv virtualenvwrapperLuego cree entornos virtuales para sus proyectos (workingdir debe existir):
pyenv local 3.9.0 # to prevent 'interpreter not found' in mkvirtualenv python -m pip install --upgrade pip setuptools wheel mkvirtualenv <venvname> -p python3.9 -a <workingdir>y cambiar entre proyectos:
workon <venvname> python -m pip install --upgrade pip setuptools wheel pipenvDentro de un proyecto tengo el archivo requirements.txt, sin arreglar las versiones dentro (si no es necesaria alguna limitación de versión). Tienes 2 herramientas posibles para instalarlas en el entorno virtual actual: pip-tools o pipenv . Digamos que usarás pipenv:
pipenv install -r requirements.txtesto creará archivos Pipfile y Pipfile.lock, las versiones corregidas están en la segunda. Si desea reinstalar en algún lugar exactamente las mismas versiones, entonces (Pipfile.lock debe estar presente):
pipenv installRecuerde que Pipfile.lock está relacionado con alguna versión de Python y debe volver a crearse si usa una diferente.
Como ves escribo requisitos.txt. Esto tiene algunos problemas: también debe eliminar un paquete eliminado de Pipfile. Así que escribir Pipfile directamente es probablemente mejor.
Entonces puedes ver que uso pipenv muy mal. ¿Tal vez si lo usas bien, puede reemplazar todo?
EDITAR 2021.01 : he cambiado mi pila a: pyenv + pyenv-virtualenvwrapper + poetry . Es decir. No uso la instalación apt o pip de virtualenv o virtualenvwrapper, y en su lugar instalo el complemento pyenv pyenv-virtualenvwrapper . Esta es una manera más fácil.
Poetry es genial para mí:
poetry add <package> # install single package poetry remove <package> poetry install # if you remove poetry.lock poetry will re-calculate versionsComencemos con los problemas que estas herramientas quieren resolver:
El administrador de paquetes de mi sistema no tiene las versiones de Python que quería o quiero instalar varias versiones de Python una al lado de la otra, Python 3.9.0 y Python 3.9.1, Python 3.5.3, etc.
Luego usa pyenv.
Quiero instalar y ejecutar varias aplicaciones con diferentes dependencias conflictivas.
Luego use virtualenv o venv. Estos son casi completamente intercambiables, la diferencia es que virtualenv admite versiones anteriores de python y tiene algunas características únicas menores, mientras que venv está en la biblioteca estándar.
Estoy desarrollando una /aplicación/ y necesito administrar mis dependencias y administrar la resolución de dependencias de las dependencias de mi proyecto.
Luego usa pipenv o poesía.
Estoy desarrollando una /biblioteca/ o un /paquete/ y quiero especificar las dependencias que los usuarios de mi biblioteca necesitan instalar
Luego use las herramientas de configuración.
Usé virtualenv, pero no me gusta que las carpetas de virtualenv estén dispersas en varias carpetas de proyectos. Quiero una gestión centralizada de los entornos y una gestión de proyectos sencilla
Luego use virtualenvwrapper. Variante: pyenv-virtualenvwrapper si también usa pyenv.
No recomendado
Como recién llegado a Python, esta pregunta me frustró infinitamente y me confundió durante meses. ¿En qué entorno virtual y administrador de paquetes debo invertir en aprender cuando sé que lo usaré en los próximos años?
El mejor artículo que responde a esta inquietante pregunta es https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/ de Jake Vanderplas. Aunque tiene algunos años, proporciona respuestas prácticas y la historia de los administradores de paquetes y entornos virtuales de Python desde las trincheras a medida que se desarrollaba este estado del arte.
Fue particularmente frustrante para mí en las comunidades de ciencia de datos y "computación en la nube de big data", porque conda se usa ampliamente como administrador de entornos virtuales y administrador de paquetes de funciones completas para Python y JavaScript, SQL, Java, HTML5 y Jupyter Notebooks.
Entonces, ¿por qué usar pip en absoluto, cuando conda hace todo lo que hacen las variantes pip y venv?
La respuesta es "porque DEBE usar pip si un paquete conda simplemente no está disponible". Muchas veces, un paquete requerido solo está disponible en formato pip y no hay una solución fácil más que usar pip. Puede aprender a usar conda build pero si no es el mantenedor del paquete, debe convencer al propietario del paquete para que genere un paquete conda para cada nueva versión (o hacerlo usted mismo).
Estos paquetes basados en pips difieren en muchas dimensiones importantes y prácticas:
Responderé a su pregunta para dos paquetes desde la dimensión de madurez y estabilidad del paquete.
venv y virtualenv son los más maduros, estables y con soporte comunitario. En la documentación en línea, puede ver que virtualenv está en la versión 20.x a partir de hoy. entorno virtual
virtualenv es una herramienta para crear entornos Python aislados. Desde Python 3.3, un subconjunto se ha integrado en la biblioteca estándar bajo el módulo venv. El módulo venv no ofrece todas las funciones de esta biblioteca, por nombrar solo algunas más destacadas:
is slower (by not having the app-data seed method), is not as extendable, cannot create virtual environments for arbitrarily installed python versions (and automatically discover these), is not upgrade-able via pip, does not have as rich programmatic API (describe virtual environments without creating them).
virtualenvwrapper es un conjunto de scripts para ayudar a las personas a usar virtualenv (es un "envoltorio" que no está bien mantenido, su última actualización fue en 2019. virtualenvwrapper
Mi recomendación es evitar TODOS los entornos virtuales pip siempre que sea posible. Utilice conda en su lugar. Conda proporciona un enfoque unificado. Es mantenido por equipos de desarrolladores profesionales de código abierto y cuenta con una empresa de renombre que proporciona financiación y una versión con soporte comercial. Los equipos que mantienen pip, venv, virtualenv, pipenv y muchas otras variantes de pip tienen recursos limitados en comparación. La pluralidad del entorno virtual pip es frustrante para los principiantes. La complejidad de las herramientas del entorno virtual basado en pip, la fragmentación, los paquetes marginales y sin soporte, y el soporte tremendamente inconsistente me llevaron a usar conda. Para el trabajo de ciencia de datos, mi recomendación es usar un administrador de entorno virtual basado en pip como último recurso cuando no existen paquetes conda.
Las diferencias entre las variantes de venv todavía me asustan porque mi tiempo es limitado para aprender nuevos paquetes. pipenv, venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, poety y otros tienen docenas de diferencias y complejidades que tardan días en comprenderse. Odio ir por un camino y encontrar soporte para un paquete que se arruina cuando un mantenedor renuncia (o está demasiado ocupado para mantenerlo). Solo necesito hacer mi trabajo.
Con el espíritu de ser útil, aquí hay algunos enlaces para ayudarlo a sumergirse en la cabeza, pero no perderse en el Infierno de Dante (re: pip).
Una guía para los entornos virtuales de Python
Es importante elegir paquetes de Python "básicos" para invertir en su carrera (a largo plazo), en lugar de hacer un trabajo a corto plazo. Sin embargo, es una cuestión de análisis empresarial. ¿Está tratando de simplemente realizar una tarea o de un ingeniero de software profesional que crea sistemas de rendimiento escalables que requieren la menor cantidad de esfuerzo de mantenimiento a lo largo del tiempo? En mi humilde opinión, conda te llevará al último lugar más fácilmente que lidiar con problemas de pluralidad de pepitas. a conda todavía le faltan herramientas de migración de paquete pip de 1 paso que hacen que esta sea una pregunta discutible. Si pudiéramos simplemente convertir paquetes pip en paquetes conda, entonces pypi.org y conda-forge podrían fusionarse. Pip es necesario porque los paquetes conda no son (todavía) universales. Muchos programadores de Python son demasiado perezosos para crear paquetes conda, o solo programan en Python y no necesitan el soporte multilingüe / agnóstico del lenguaje de conda.
conda ha sido una bendición para mí, porque es compatible con la ingeniería de software en la nube y la necesidad de la ciencia de datos de soporte multilingüe de las extensiones de JavaScript, SQL y Jupyter Notebook, y conda funciona bien en Docker y otros entornos nativos de la nube. Lo animo a aprender y dominar conda, lo que le permitirá esquivar muchas preguntas complejas que las herramientas basadas en pip nunca pueden responder.
¡Mantenlo simple! Necesito un paquete que haga el 90 % de lo que necesito y orientación y soluciones alternativas para el 10 % restante de los casos extremos.
Consulte los artículos vinculados aquí para obtener más información sobre los entornos virtuales basados en pip.
Espero que esto sea útil para el cartel original y les dé a los aficionados a pip y conda algunas cosas en las que pensar.