Si está utilizando el módulo venv que viene con Python 3.3+, admite una opción --upgrade. Por el docs:

Actualice el directorio de entorno para usar esta versión de Python, suponiendo que Python se haya actualizado in-place

python3 -m venv --upgrade ENV_DIR

Actualizado de nuevo: Es posible que el siguiente método no funcione en versiones más recientes de virtualenv. Antes de intentar hacer modificaciones al viejo 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, todavía puede crear un nuevo virtualenv e instalar las dependencias antiguas en él (pip install -r requirements.txt).

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

Efecto secundario: también corrige la excepción Symbol not found: _SSLv2_method cuando lo hace import ssl en un entorno virtual después de actualizar Python a la versión 2.7.8.

Aviso: Actualmente, esto es para Python 2.7.x only .

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

brew update && brew upgrade python

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

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 básicos antiguos de Python y las bibliotecas estándar (además de setuptools y pip), mientras que las bibliotecas personalizadas instaladas en site-packages se 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 compilemessages no es trabajando después, prueba esto:

brew install gettext && brew link gettext --force

No pude crear un nuevo virtualenv encima del anterior. Pero hay herramientas en pip que hacen que sea mucho más rápido volver a instalar los requisitos en un nuevo venv. Pip puede construir cada uno de los elementos en sus requisitos.txt en un paquete wheel, y almacenar en un caché local. Cuando crea un nuevo venv y ejecuta pip install en él, pip usará automáticamente las ruedas prediseñadas si las encuentra. Las ruedas se instalan mucho más rápido que correr 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 la rueda-dir en mi pip.conf.

A partir de entonces, cada vez que instalo pip 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 usar python3 -m venv, no admite entornos Python 2
• Cuando comienzo un nuevo proyecto, utilizo mkproject que crea el entorno virtual, crea un directorio de proyecto vacío, y cds en él
• Quiero continuar usando el comando workon de virtualenvwrapper para activar cualquier proyecto independientemente de la versión de Python

Direcciones:

Digamos que su proyecto existente se llama foo y actualmente está ejecutando Python 2 (mkproject -p python2 foo), aunque los comandos son los mismos si actualiza desde 2.x a 3.x, 3.6.0 a 3.6.1, etc. También asumo que actualmente estás dentro del entorno virtual activado.

1. Desactivar y eliminar el antiguo entorno virtual:

$ deactivate
$ rmvirtualenv foo

Tenga en cuenta que si ha agregado algún comando personalizado a los hooks (por ejemplo, bin/postactivate) deberá guardarlo antes de eliminar el entorno.

2. Guarda el proyecto real en un directorio temporal:

$ cd ..
$ mv foo foo-tmp

3. Crea el nuevo entorno virtual (y dir del proyecto) y activa:

$ mkproject -p python3 foo

4. Reemplazar el dir de proyecto generado vacío con un proyecto real, cambiar de nuevo a project dir:

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

5. Reinstalar dependencias, confirmar 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 PR para agregar algo como $ upgradevirtualenv / $ upgradeproject a virtualenvwrapper.

Moví mi directorio personal de un mac a otro (Mountain Lion a Yosemite) y no me di cuenta del virtualenv roto hasta que perdí el control de la vieja computadora portátil. Tenía el punto virtualenv a Python 2.7 instalado por brew y como Yosemite vino con Python 2.7, quería actualizar mi virtualenv al sistema python. Cuando corrí virtualenv en la parte superior del directorio existente, estaba recibiendo OSError: [Errno 17] File exists: '/Users/hdara/bin/python2.7/lib/python2.7/config' error. Por ensayo y error, trabajé alrededor de 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 en la parte superior del directorio existente.

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

Guardé lo siguiente en upgrade_python3.sh así que recordaría cómo meses a partir de ahora cuando tengo que hacerlo de nuevo:

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 corrí py.prueba dio un error. Al final, solo recreé el entorno a partir de un archivo de requisitos.

Si está utilizando pipenv, no se 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 a venv y otras se refieren a virtualenv.

El uso de la bandera -p o --python se admite en virtualenv, pero no en venv. Si tiene más de una versión de Python y desea especificar con cuál crear venv, hágalo en la línea de comandos, así:

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

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