¿Hay alguna manera de actualizar la versión de python utilizada en un virtualenv (por ejemplo, si sale una versión de corrección de errores)?

Podría pip freeze --local > requirements.txt, luego eliminar el directorio y pip install -r requirements.txt, pero esto requiere mucha reinstalación de grandes bibliotecas, por ejemplo numpy, que uso mucho.

Puedo ver que esto es una ventaja cuando actualizo desde, por ejemplo, 2.6 -> 2.7, pero ¿qué pasa con 2.7.x -> 2.7.y?

¿Viste esto ? Si no he entendido mal esa respuesta, puede intentar crear un nuevo virtualenv sobre el anterior. Solo necesita saber qué python utilizará su virtualenv (deberá ver su versión virtualenv).

Si su virtualenv está instalado con la misma versión de python que la anterior y la actualización de su paquete virtualenv no es una opción, puede leer esto para instalar un virtualenv con la versión de python que desee.

EDITAR

He probado este enfoque (el que crea un nuevo virtualenv sobre el anterior) y funcionó bien para mí. Creo que puede tener algunos problemas si cambia de Python 2.6 a 2.7 o 2.7 a 3.x, pero si solo actualiza dentro de la misma versión (permaneciendo en 2.7 como desee) no debería tener ningún problema, ya que todos los paquetes se mantienen en las mismas carpetas para ambas versiones de python (los paquetes 2.7.xy 2.7.y están dentro de your_env / lib / python2.7 /).

Si cambia su versión de python virtualenv, deberá instalar todos sus paquetes nuevamente para esa versión (o simplemente vincular los paquetes que necesita a la carpeta de paquetes de la nueva versión, es decir: your_env / lib / python_newversion / site-packages)

Si está utilizando el módulo venv que viene con Python 3.3+, es compatible con una --upgradeopción. Por los documentos :

Actualice el directorio del entorno para usar esta versión de Python, suponiendo que Python se haya actualizado en el lugar

python3 -m venv --upgrade ENV_DIR

Actualizado nuevamente: el siguiente método podría no funcionar en versiones más recientes de virtualenv. Antes de intentar hacer modificaciones al antiguo virtualenv, debe guardar las dependencias en un archivo de requisitos (pip freeze > requirements.txt) y hacer una copia de seguridad de él en otro lugar. Si algo sale mal, aún puede crear un nuevo virtualenv e instalar las antiguas dependencias en él (pip install -r requirements.txt).

Actualizado: cambié la respuesta 5 meses después de haber respondido originalmente. El siguiente método es más conveniente y robusto.

Efecto secundario: también corrige laSymbol not found: _SSLv2_methodexcepción cuando lo haceimport sslen un entorno virtual después de actualizar Python a v2.7.8.

Aviso: En la actualidad, esto es sólo el 2.7.x Python .

Si está utilizando Homebrew Python en OS X, primero deactivatetodo virtualenv, luego actualice Python:

brew update && brew upgrade python

Ejecute los siguientes comandos ( <EXISTING_ENV_PATH>es la ruta de su entorno virtual):

cd <EXISTING_ENV_PATH>
rm .Python
rm bin/pip{,2,2.7}
rm bin/python{,2,2.7}
rm -r include/python2.7
rm lib/python2.7/*
rm -r lib/python2.7/distutils
rm lib/python2.7/site-packages/easy_install.*
rm -r lib/python2.7/site-packages/pip
rm -r lib/python2.7/site-packages/pip-*.dist-info
rm -r lib/python2.7/site-packages/setuptools
rm -r lib/python2.7/site-packages/setuptools-*.dist-info

Finalmente, vuelva a crear su entorno virtual:

virtualenv <EXISTING_ENV_PATH>

Al hacerlo, se eliminan los archivos centrales antiguos de Python y las bibliotecas estándar (más setuptoolsy pip), mientras que las bibliotecas personalizadas instaladas site-packagesse conservan y funcionan, tan pronto como estén en Python puro. Las bibliotecas binarias pueden o no necesitar ser reinstaladas para funcionar correctamente.

Esto funcionó para mí en 5 entornos virtuales con Django instalado.

Por cierto, si ./manage.py compilemessagesno funciona después, intente esto:

brew install gettext && brew link gettext --force

No pude crear un nuevo virtualenv sobre el anterior. Pero hay herramientas en pip que hacen que sea mucho más rápido reinstalar los requisitos en una nueva versión. Pip puede compilar cada uno de los elementos en su require.txt en un paquete de rueda y almacenarlo en un caché local. Cuando crea un nuevo venv y ejecuta la instalación de pip en él, pip usará automáticamente las ruedas preconstruidas si las encuentra. Las ruedas se instalan mucho más rápido que ejecutar setup.py para cada módulo.

Mi ~ / .pip / pip.conf se ve así:

[global]
download-cache = /Users/me/.pip/download-cache
find-links =
/Users/me/.pip/wheels/

[wheel]
wheel-dir = /Users/me/.pip/wheels

Instalo wheel ( pip install wheel), luego corro pip wheel -r requirements.txt. Esto almacena las ruedas construidas en el directorio de rueda en mi pip.conf.

A partir de entonces, cada vez que instalo cualquiera de estos requisitos, los instala desde las ruedas, lo cual es bastante rápido.

Cómo actualizar la versión de Python para un proyecto virtualenvwrapper existente y mantener el mismo nombre

Estoy agregando una respuesta para cualquiera que use el excelente virtualenvwrapper de Doug Hellmann específicamente porque las respuestas existentes no lo hicieron por mí.

Algún contexto:

• Trabajo en algunos proyectos que son Python 2 y algunos que son Python 3; aunque me encantaría usarlo python3 -m venv, no es compatible con entornos Python 2
• Cuando comienzo un nuevo proyecto, uso el mkprojectque crea el entorno virtual, crea un directorio de proyecto vacío y lo graba en CD.
• Quiero seguir usando el workoncomando virtualenvwrapper para activar cualquier proyecto independientemente de la versión de Python

Direcciones:

Digamos que su proyecto existente se llama fooy actualmente ejecuta Python 2 ( mkproject -p python2 foo), aunque los comandos son los mismos si se actualiza de 2.xa 3.x, 3.6.0 a 3.6.1, etc. También supongo que ' Actualmente está dentro del entorno virtual activado.

1. Desactive y elimine el antiguo entorno virtual:

$ deactivate
$ rmvirtualenv foo

Tenga en cuenta que si ha agregado comandos personalizados a los ganchos (p. Ej. bin/postactivate), Deberá guardarlos antes de eliminar el entorno.

2. Guarde el proyecto real en un directorio temporal:

$ cd ..
$ mv foo foo-tmp

3. Cree el nuevo entorno virtual (y el directorio del proyecto) y active:

$ mkproject -p python3 foo

4. Reemplace el directorio de proyecto generado vacío con proyecto real, cambie nuevamente al directorio de proyecto:

$ cd ..
$ mv -f foo-tmp foo
$ cdproject

5. Vuelva a instalar las dependencias, confirme la nueva versión de Python, etc.

$ pip install -r requirements.txt
$ python --version

Si este es un caso de uso común, consideraré abrir un RP para agregar algo como $ upgradevirtualenv/ $ upgradeprojecta virtualenvwrapper.

Este enfoque siempre funciona para mí:

# First of all, delete all broken links. Replace  my_project_name` to your virtual env name
find ~/.virtualenvs/my_project_name/ -type l -delete
# Then create new links to the current Python version
virtualenv ~/.virtualenvs/my_project_name/
# It's it. Just repeat for each virtualenv located in ~/.virtualenvs

Tomado de:

• https://github.com/1st/python-on-osx#python-virtualenv
• https://gist.github.com/1st/ced02a1c64ac7b82bb27e432eea6b068

Moví mi directorio de inicio de un mac a otro (Mountain Lion a Yosemite) y no me di cuenta sobre el virtualenv roto hasta que perdí el control de la vieja computadora portátil. Tuve el punto virtualenv de instalar Python 2.7 brewy desde que Yosemite vino con Python 2.7, quería actualizar mi virtualenv al sistema python. Cuando corrí virtualenvsobre el directorio existente, recibí un OSError: [Errno 17] File exists: '/Users/hdara/bin/python2.7/lib/python2.7/config'error. Por prueba y error, solucioné este problema eliminando algunos enlaces y arreglando algunos más manualmente. Esto es lo que finalmente hice (similar a lo que hizo @Rockalite, pero más simple):

cd <virtualenv-root>
rm lib/python2.7/config
rm lib/python2.7/lib-dynload
rm include/python2.7
rm .Python
cd lib/python2.7
gfind . -type l -xtype l | while read f; do ln -s -f /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/${f#./} $f; done

Después de esto, pude ejecutar virtualenv sobre el directorio existente.

En OS X o macOS usando Homebrew para instalar y actualizar Python3 tuve que eliminar enlaces simbólicos antes de python -m venv --upgrade ENV_DIRque funcionara.

Guardé lo siguiente en upgrade_python3.sh para recordar cómo dentro de unos meses, cuando necesite volver a hacerlo:

brew upgrade python3
find ~/.virtualenvs/ -type l -delete
find ~/.virtualenvs/ -type d -mindepth 1 -maxdepth 1 -exec python3 -m venv --upgrade "{}" \;

ACTUALIZACIÓN: si bien esto parecía funcionar bien al principio, cuando ejecuté py.test me dio un error. Al final, acabo de volver a crear el entorno a partir de un archivo de requisitos.

Si está utilizando pipenv, no sé si es posible actualizar un entorno en su lugar, pero al menos para actualizaciones de versiones menores, parece ser lo suficientemente inteligente como para no reconstruir paquetes desde cero cuando crea un nuevo entorno. Por ejemplo, de 3.6.4 a 3.6.5:

$ pipenv --python 3.6.5 install
Virtualenv already exists!
Removing existing virtualenv…
Creating a v$ pipenv --python 3.6.5 install
Virtualenv already exists!
Removing existing virtualenv…
Creating a virtualenv for this project…
Using /usr/local/bin/python3.6m (3.6.5) to create virtualenv…
⠋Running virtualenv with interpreter /usr/local/bin/python3.6m
Using base prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/python3.6
Also creating executable in /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD
Installing dependencies from Pipfile.lock (84dd0e)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 47/47 — 00:00:24
To activate this project's virtualenv, run the following:
 $ pipenv shell
$ pipenv shell
Spawning environment shell (/bin/bash). Use 'exit' to leave.
. /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/activate
bash-3.2$ . /Users/dmoles/.local/share/virtualenvs/autoscale-aBUhewiD/bin/activate
(autoscale-aBUhewiD) bash-3.2$ python
Python 3.6.5 (default, Mar 30 2018, 06:41:53) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>>

Solo quiero aclarar, porque algunas de las respuestas se refieren venvy otras se refieren virtualenv.

El uso de la bandera -po --pythones compatible virtualenv, pero no activado venv. Si tiene más de una versión de Python y desea especificar con cuál crearla venv, hágalo en la línea de comando, así:

malikarumi@Tetuoan2:~/Projects$ python3.6 -m venv {path to pre-existing dir you want venv in}

Por supuesto, puede actualizar venvcomo lo han señalado otros, pero eso supone que ya ha actualizado el Python que se utilizó para crear eso venven primer lugar. No puede actualizar a una versión de Python que aún no tiene en su sistema en algún lugar, así que asegúrese de obtener la versión que desea, primero, luego haga todos los venvs que desee.

Paso 1: congele el requisito y realice una copia de seguridad del entorno existente

pip freeze > requirements.txt
deactivate
mv env env_old

Paso 2: Instale Python 3.7 y active el entorno virutal

sudo apt-get install python3.7-venv
python3.7 -m venv env
source env/bin/activate
python --version

Paso 3: instale los requisitos

sudo apt-get install python3.7-dev
pip3 install -r requirements.txt

Para todos los que tienen el problema.

Error: Comando '[' / Users / me / Sites / site / venv3 / bin / python3 ',' -Im ',' surepip ',' --upgrade ',' --default-pip ']' devuelto distinto de cero estado de salida 1.

Tienes que instalar python3.6-venv

 sudo apt-get install python3.6-venv