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 ?
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 utilizo 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 versionsActualizació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:
Comencemos 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
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