Vuelva a instalar los paquetes automáticamente en el entorno virtual después de la actualización de la versión principal de Python

Tengo varios entornos virtuales (docenas) en mi disco creados por el venvmódulo de Python 3.6. Ahora me he actualizado a Ubuntu 19.10 a toda prisa y solo después noté que 3.6 no está disponible para Ubuntu 19.10 de las fuentes generalmente reconocidas. Me las arreglé para actualizar las versiones de Python de estos entornos virtuales al ubicarlas bin/python3en mi directorio de inicio y ejecutarlas python3.7 -mvenv --upgradeen las carpetas que las contienen.

Ahora, mientras que python3.7 -mvenv --upgradelas actualizaciones del pitón en el entorno virtual, no hace nada para volver a instalar mis versiones de los paquetes anteriores en el lib/python3.7/site-packagesbajo ese venv. Supongo que podría haber hecho esto instalando Python 3.6, pip freezeing los requisitos del venvy luego actualizando el venv a Python 3.7, pip install -ring - si solo hubiera una instalación de Python 3.6 disponible para mi nuevo sistema operativo.

¿Hay alguna otra manera de hacer esto de una manera bastante automatizada (quizás principalmente pip freezeusando el lib/python3.6directorio anterior) sin que tenga que instalar Python 3.6 desde la fuente, usar conda o instalar 3.6 desde algunos PPA aleatorios? Quiero actualizar todos los entornos en masa para que en el futuro, cuando necesite hacer algo con un entorno aleatorio, continúe funcionando con Python 3.7.

En su nuevo 3.7 venv que debería tener pkg_resourcesdisponible, setuptoolsse instala automáticamente cuando se crea. Si no, solo pip install setuptools.

setuptoolsEl código de la biblioteca es en realidad lo que se pipestá vendiendo para que pip freezefuncione. Pero puedes congelarlo manualmente.

# in 3.7 runtime...
import pkg_resources
old_site_dir = ".venv/lib/python3.6/site-packages/"
working_set = pkg_resources.WorkingSet([old_site_dir])
for dist in working_set:
    print(dist.as_requirement())

Puede lanzar esa salida en un requirements.txtarchivo y probablemente tenga un sitio reconstruido que funcione, no se python3.6requiere tiempo de ejecución.

Tenga en cuenta que este método puede no ser 100% infalible, porque es posible que los proyectos declaren árboles de dependencia separados para python3.6 y python3.7 mediante el uso de marcadores de entorno en sus metadatos de distribución (consulte PEP 508 ). También es posible que los elementos instalados en su sitio 3.6 no son compatibles con 3.7 en absoluto . Sin embargo, es bastante raro ver que en una versión menor se encuentre entre 3.6 y 3.7, por lo que solo usar el conjunto de trabajo debería ser "lo suficientemente bueno" en la práctica.