Ponownie zainstaluj pakiety automatycznie w środowisku wirtualnym po aktualizacji głównej wersji Pythona

Mam kilka wirtualnych środowisk (dziesiątki) leżących na moim dysku wykonanym przez venvmoduł Pythona 3.6. Teraz uaktualniłem do Ubuntu 19.10 w pośpiechu i dopiero później zauważyłem, że 3.6 nie jest w ogóle dostępny dla Ubuntu 19.10 z ogólnie uznanych źródeł. Udało mi się zaktualizować wersje tych środowisk wirtualnych w języku Python, znajdując się bin/python3w katalogu domowym i uruchamiając python3.7 -mvenv --upgradefoldery zawierające.

Teraz, chociaż python3.7 -mvenv --upgradeaktualizuje Python w środowisku wirtualnym, nie robi nic, aby ponownie zainstalować moje poprzednie wersje pakietów w lib/python3.7/site-packagestym venv. Wydaje mi się, że mógłbym to zrobić, instalując Python 3.6, pobierając pip freezewymagania od, venva następnie uaktualniając venv do Pythona 3.7, pip install -ring - gdyby tylko dostępna była instalacja Python 3.6 dla mojego nowego systemu operacyjnego.

Czy jest jakiś inny sposób, aby to zrobić w raczej zautomatyzowany sposób (być może głównie przy pip freezeużyciu starego lib/python3.6katalogu) bez konieczności instalowania Pythona 3.6 ze źródła, używania conda lub instalacji 3.6 z niektórych losowych PPA? Chcę masowo zaktualizować wszystkie środowiska, aby w przyszłości, gdy będę musiał coś zrobić z przypadkowym środowiskiem, kontynuował pracę z Pythonem 3.7.

W nowym Venv 3.7 powinieneś być pkg_resourcesdostępny - setuptoolsjest instalowany automatycznie po utworzeniu. Jeśli nie, tylko pip install setuptools.

setuptoolskod biblioteki jest w rzeczywistości tym, co pipsprzedaje, aby pip freezedziałało. Ale możesz po prostu zamrozić ręcznie.

# 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())

Możesz wrzucić te dane wyjściowe do requirements.txtpliku i prawdopodobnie mieć działającą zrekonstruowaną witrynę, nie jest python3.6wymagane żadne środowisko wykonawcze.

Zauważ, że ta metoda może nie być w 100% niezawodna, ponieważ projekty mogą zadeklarować osobne drzewa zależności dla python3.6 i python3.7 za pomocą znaczników środowiska w swoich metadanych dystrybucji (patrz PEP 508 ). Możliwe jest również, że elementy zainstalowane w miejscu 3.6 3.7 nie obsługują w ogóle . Jednak dość rzadkie jest zauważanie, że w mniejszej wersji guzy między 3.6 a 3.7, więc samo użycie zestawu roboczego powinno być „wystarczająco dobre” w praktyce.