Python 3.3 incluye en su biblioteca estándar el nuevo paquete venv. ¿Qué hace y cómo difiere de todos los otros paquetes que parecen coincidir con la expresión regular (py)?(v|virtual|pip)?env?

Paquetes PyPI que no están en la biblioteca estándar:

• virtualenves una herramienta muy popular que crea entornos aislados de Python para bibliotecas de Python. Si no está familiarizado con esta herramienta, le recomiendo que la aprenda, ya que es una herramienta muy útil, y haré comparaciones con ella para el resto de esta respuesta.

  Funciona instalando un grupo de archivos en un directorio (por ejemplo:) env/, y luego modificando la PATHvariable de entorno para prefijarlo con un bindirectorio personalizado (por ejemplo:) env/bin/. Se coloca una copia exacta del pythono python3binario en este directorio, pero Python está programado para buscar bibliotecas en relación con su ruta primero, en el directorio del entorno. No es parte de la biblioteca estándar de Python, pero es bendecida oficialmente por PyPA (Python Packaging Authority). Una vez activado, puede instalar paquetes en el entorno virtual mediante pip.

• pyenvse utiliza 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 cambiar entre ellos. Una vez activado, antepone la PATHvariable de entorno 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 según la PYENV_VERSIONvariable de entorno, o el .python-versionarchivo o el ~/.pyenv/versionarchivo. pyenvTambién facilita el proceso de descarga e instalación de múltiples versiones de Python, utilizando el comando pyenv install.

• pyenv-virtualenves un complemento para pyenvel mismo autor que pyenv, para permitirle usar pyenvy virtualenval mismo tiempo convenientemente. Sin embargo, si está utilizando Python 3.3 o posterior, pyenv-virtualenvintentará ejecutarlo python -m venvsi está disponible, en lugar de hacerlo virtualenv. Puede usar virtualenvy pyenvjuntos sin pyenv-virtualenv, si no desea las funciones de conveniencia.

• virtualenvwrapperes un conjunto de extensiones para virtualenv(ver documentos ). Le da comandos como mkvirtualenv, lssitepackagesy especialmente workonpara cambiar entre diferentes virtualenvdirectorios. Esta herramienta es especialmente útil si desea múltiples virtualenvdirectorios.

• pyenv-virtualenvwrapperes un plugin para pyenvel mismo autor que pyenv, para integrar convenientemente virtualenvwrapperen pyenv.

• pipenvpretende combinar Pipfile, pipy virtualenven un comando en la línea de comandos. El virtualenvdirectorio generalmente se coloca en ~/.local/share/virtualenvs/XXX, XXXsiendo un hash de la ruta del directorio del proyecto. Esto es diferente de virtualenv, donde el directorio está típicamente en el directorio de trabajo actual. pipenvestá destinado a usarse al desarrollar aplicaciones de Python (a diferencia de las bibliotecas). Hay alternativas a pipenv, como poetry, que no enumeraré aquí, ya que esta pregunta es solo sobre los paquetes que tienen nombres similares.

Biblioteca estándar:

• pyvenves un script enviado con Python 3 pero desaprobado en Python 3.6 ya que tenía problemas (sin mencionar el nombre confuso). En Python 3.6+, el equivalente exacto es python3 -m venv.

• venves 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-venven Ubuntu / Debian). Sirve para el mismo propósito virtualenv, pero solo tiene un subconjunto de sus características ( vea una comparación aquí ). virtualenvsigue siendo más popular que venv, especialmente porque el primero es compatible con Python 2 y 3.

Recomendación para principiantes:

Esta es mi recomendación personal para principiantes: comience por aprender virtualenvy 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.

Simplemente evitaría el uso de virtualenvdespué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>  

virtualenvintenta 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 construye Python desde la fuente en un directorio que no sea del sistema con nombres de ruta relativos, el binario de Python se rompe. Como así es como se hace una copia distribuible de Python, es un gran defecto. Por cierto, para inspeccionar 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 virtualenvwrappery pipenv. pyvenves obsoleto. pyenvParece que se usa a menudo donde virtualenvse usa, pero también me mantendría alejado de él, ya que creo que venvtambién hace para lo que pyenvestá diseñado.

venvcrea entornos virtuales en el shell que son frescos y de espacio aislado , con bibliotecas instalables por el usuario , y es seguro para múltiples python . Fresco porque los entornos virtuales solo comienzan con las bibliotecas estándar que se envían con python, debe instalar nuevamente cualquier otra biblioteca pip installmientras el entorno virtual esté activo. Sandboxed porque ninguna de estas nuevas instalaciones de la biblioteca es visible fuera del entorno virtual, por lo que puede eliminar todo el entorno y comenzar de nuevo sin preocuparse por afectar la instalación de Python base. Bibliotecas instalables por el usuario porque la carpeta de destino del entorno virtual se crea sinsudoen algún directorio que ya posee, por lo que no necesitará sudopermisos para instalar bibliotecas en él. Finalmente, es seguro para múltiples python , ya que cuando se activan entornos virtuales, el shell solo ve la versión de python (3.4, 3.5, etc.) que se utilizó para construir ese entorno virtual.

pyenves similar a venvque le permite administrar múltiples entornos de Python. Sin embargo, pyenvno puede revertir cómodamente las instalaciones de la biblioteca a algún estado de inicio y es probable que necesite adminprivilegios en algún momento para actualizar las bibliotecas. Así que creo que también es mejor usarlo venv.

En los últimos años, he encontrado muchos problemas en los sistemas de compilación (paquetes de emacs, constructores de aplicaciones independientes de Python, instaladores ...) que finalmente tienen problemas virtualenv. Creo que Python será una mejor plataforma cuando eliminemos esta opción adicional y solo la usemos venv.

He bajado por la pipenvmadriguera del conejo (de hecho es una madriguera profunda y oscura ... ) y desde que la última respuesta fue hace más de 2 años , sentí que era útil actualizar la discusión con los últimos desarrollos sobre el tema de sobres virtuales de Python I Lo he encontrado.

DESCARGO DE RESPONSABILIDAD:

Esta respuesta es NO sobre la continuación de la discusión que rabia sobre los méritos de pipenv frente Venv como sobre soluciones- me hacen ningún endoso de cualquiera . Se trata de que PyPA respalde estándares conflictivos y de cómo el desarrollo futuro de virtualenv promete negar la elección de uno u otro. Me concentré en estas dos herramientas precisamente porque son las ungidas por PyPA .

venv

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 venv para crear SOBRES VIRTUALES : " Modificado en la versión 3.5: ahora se recomienda el uso de venv para crear entornos virtuales ".

pipenv

pipenv , al igual que venv , se puede usar para crear sobres virtuales, pero adicionalmente incluye la administración de paquetes y lafuncionalidad de comprobación de vulnerabilidades . En lugar de usarrequirements.txt,pipenvofrece administración de paquetes a través de Pipfile . Como PyPA respalda pipenv para la GESTIÓN DE PAQUETES , eso parece implicar quepipfilees suplantarrequirements.txt .

SIN EMBARGO : pipenv usa virtualenv como su herramienta para crear sobres virtuales, NO venv, que está respaldado por PyPA como la herramienta de para crear sobres virtuales.

Estándares en conflicto:

Entonces, si decidirse por una solución de sobre virtual no fue lo suficientemente difícil, ahora tenemos PyPA que respalda dos herramientas diferentes que usan diferentes soluciones de sobre virtual. El furioso debate de Github sobre venv vs virtualenv que destaca este conflicto se puede encontrar aquí .

La resolución de conflictos:

El debate de Github al que se hace referencia en el enlace anterior ha dirigido el desarrollo virtualenv en la dirección de acomodar venv en futuras versiones :

preferir venv incorporado: si el python objetivo tiene venv crearemos el entorno utilizando eso (y luego realizaremos operaciones posteriores para facilitar otras garantías que ofrecemos)

Conclusión:

Por lo tanto, parece que habrá una convergencia futura entre las dos soluciones de envoltura virtual rivales, pero a partir de ahora pipenv , que utiliza virtualenv, varía materialmente 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 .

Actualización de abril de 2020

Estaba buscando lo mismo cuando me encontré con esta publicación . Creo que este problema de qué herramienta usar es bastante confuso y difícil para los nuevos usuarios de Python como yo. Esto es directamente desde el sitio web de PyPA con respecto a pipenv:

Si bien este tutorial cubre el proyecto pipenv como una herramienta que se enfoca principalmente en las necesidades del desarrollo de aplicaciones Python en lugar del desarrollo de la biblioteca Python, el proyecto en sí está trabajando en varios problemas de proceso y mantenimiento que impiden la publicación de correcciones de errores y nuevas características ( con la totalidad de 2019 pasando sin un nuevo lanzamiento). Esto significa que en el corto plazo, pipenv todavía sufre de varias peculiaridades y problemas de rendimiento sin una línea de tiempo clara para la resolución de esos problemas.

Si bien este sigue siendo el caso, es probable que los encargados del mantenimiento del proyecto quieran investigar Otras herramientas para la gestión de la dependencia de aplicaciones para su uso en lugar de, o junto con, pipenv.

Suponiendo que el lanzamiento de pipenv en abril de 2020 se lleva a cabo según lo planeado, y el lanzamiento después de eso también sigue en camino, entonces esta advertencia en el tutorial se eliminará. Si esos lanzamientos no se mantienen en curso, el tutorial en sí se eliminará y se reemplazará con una página de discusión sobre las opciones de administración de dependencias disponibles.