Reinstale os pacotes automaticamente no ambiente virtual após a atualização da versão principal do Python

Eu tenho vários ambientes virtuais (dezenas) no meu disco criados pelo venvmódulo do Python 3.6. Agora eu atualizei para o Ubuntu 19.10 às pressas e só depois notei que o 3.6 não está disponível para o Ubuntu 19.10 a partir das fontes geralmente reconhecidas. Eu consegui atualizar as versões Python desses ambientes virtuais localizando bin/python3no meu diretório pessoal e executando python3.7 -mvenv --upgradenas pastas que os contêm.

Agora, enquanto python3.7 -mvenv --upgradeas atualizações do Python no ambiente virtual, ele não faz nada para reinstalar minhas versões de pacotes anteriores no lib/python3.7/site-packagessob esse venv. Acho que eu poderia ter feito isso instalando o Python 3.6, adicionando pip freezeos requisitos venve atualizando o venv para o Python 3.7, pip install -ring - se houvesse apenas a instalação do Python 3.6 disponível para o meu novo sistema operacional.

Existe alguma outra maneira de fazer isso de uma maneira bastante automatizada (talvez principalmente pip freezeusando o lib/python3.6diretório antigo ) sem que eu precise instalar o Python 3.6 a partir da fonte, usando o conda ou instalando o 3.6 a partir de alguns PPAs aleatórios? Quero atualizar todos os ambientes em massa para que, no futuro, quando eu precise fazer algo com um ambiente aleatório, continue trabalhando com o Python 3.7.

No seu novo 3.7 venv, você deve ter pkg_resourcesdisponível - setuptoolsé instalado automaticamente quando criado. Se não, apenas pip install setuptools.

setuptoolso código da biblioteca é, na verdade, o que o pipvendedor faz para dar certo pip freeze. Mas você pode congelá-lo 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())

Você pode lançar essa saída em um requirements.txtarquivo e provavelmente possui um site reconstruído, sem necessidade de python3.6tempo de execução.

Observe que esse método pode não ser 100% infalível, porque é possível que os projetos declarem árvores de dependência separadas para python3.6 e python3.7 usando marcadores de ambiente em seus metadados de distribuição (consulte PEP 508 ). Também é possível que os itens instalados em seu 3.6 local não suportam 3,7 em tudo . No entanto, é bastante incomum ver que, em uma versão menor, entre 3.6 e 3.7, apenas usar o conjunto de trabalho deve ser "bom o suficiente" na prática.