Reinstalla automaticamente i pacchetti nell'ambiente virtuale dopo l'aggiornamento della versione principale di Python

Ho diversi ambienti virtuali (dozzine) sul mio disco creati dal venvmodulo di Python 3.6. Ora ho eseguito l'aggiornamento a Ubuntu 19.10 in fretta e solo successivamente ho notato che 3.6 non è affatto disponibile per Ubuntu 19.10 dalle fonti generalmente riconosciute. Sono riuscito ad aggiornare le versioni Python di questi ambienti virtuali individuando bin/python3nella mia directory home ed eseguendo python3.7 -mvenv --upgradele cartelle contenenti.

Ora, mentre python3.7 -mvenv --upgradeaggiorna Python nell'ambiente virtuale, non fa nulla per reinstallare le mie precedenti versioni del pacchetto in quella lib/python3.7/site-packagessotto venv. Immagino che avrei potuto farlo installando Python 3.6, pip freezeinserendo i requisiti da venve quindi aggiornando il venv a Python 3.7, sepip install -r - solo Python 3.6 fosse disponibile per il mio nuovo sistema operativo.

C'è un altro modo per farlo in modo piuttosto automatizzato (forse principalmente pip freezeusando la vecchia lib/python3.6directory) senza che io debba installare Python 3.6 dal sorgente, usare conda o installare 3.6 da alcuni PPA casuali? Voglio aggiornare tutti gli ambienti in modo che in futuro, quando avrò bisogno di fare qualcosa con un ambiente casuale, continui a lavorare con Python 3.7.

Nel nuovo 3.7 Venv dovresti avere a pkg_resourcesdisposizione - setuptoolsviene installato automaticamente quando viene creato. Altrimenti, solo pip install setuptools.

setuptoolsil codice della libreria è in realtà ciò che pipsta vendendo per far pip freezefunzionare. Ma puoi semplicemente 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())

Puoi lanciare quell'output in un requirements.txtfile e probabilmente avere un sito ricostruito funzionante, nopython3.6 necessario il runtime.

Si noti che questo metodo potrebbe non essere infallibile al 100%, poiché è possibile che i progetti dichiarino alberi di dipendenza separati per python3.6 e python3.7 utilizzando i marcatori di ambiente nei loro metadati di distribuzione (vedere PEP 508 ). E 'anche possibile che le voci installate nel vostro sito 3.6 non supportano 3,7 affatto . Tuttavia è abbastanza raro vedere che in una versione minore si verifica un bump tra 3.6 e 3.7, quindi usare il set di lavoro dovrebbe essere "abbastanza buono" in pratica.