Uma proposta ambiciosa!

suporte de configuração ini (uma configuração ini global presente na casa do usuário)

Considere o uso de appdirs (ou semelhante) para descobrir a configuração em locais preferenciais da plataforma.

appdirs também pode ser uma opção, embora então precisaríamos iniciar o negócio de vender coisas em nosso pacote. Para ser justo 70% disso já está feito, só precisaria de uma reorganização melhor.

Por que vender em vez de depender apenas dele? (Não que seja difícil de vender, é apenas um único arquivo). IMO, realmente precisamos aceitar que (com a notável exceção do pip) ferramentas de empacotamento realmente devem ser construídas como qualquer outro aplicativo. Se ter dependências é suficientemente difícil para que os aplicativos PyPA as evitem, o que isso diz sobre o quão bem estamos facilitando o desenvolvimento de aplicativos para nossos usuários?

(Desculpe, não estou falando muito sobre o virtualenv aqui, só vejo tantas pessoas dizendo "adicionar uma dependência de PyPI não é grande coisa", então as ferramentas PyPA com as quais trabalho em vendas me fazem pensar ...) .

Sem vender, o recurso de intérprete cruzado será difícil, eu acho. Por exemplo, criar um ambiente virtual para um intérprete sem o virtualenv instalado.

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

Uh, isso significa que não podemos depender de nenhum pacote adicional do virtualenv. Como forneceremos um zipapp, quais casos de uso isso permite?

@gaborbernat Você quer dizer a opção -p ? Eu acho. Parece exatamente o tipo de situação para a qual os zipapps pretendiam ajudar, mas ninguém jamais fez muito para descobrir os detalhes de como fazê-lo funcionar bem.

De @pradyunsg :

Uh, isso significa que não podemos depender de nenhum pacote adicional do virtualenv

Na verdade, como @gaborbernat disse, a opção -p provavelmente implica que :-( Mas eu me pergunto por que precisamos da opção "roda PYTHONPATH " e também do zipapp - especialmente considerando que rodas em PYTHONPATH não são suportados em geral (nós os usamos internamente no virtualenv por causa dos motivos usuais de inicialização do pip - o pip é praticamente uma exceção para tudo ;-))

período de

Hum...

Minha preocupação aqui é que os efeitos de rede disso podem causar lentidão na adoção de versões mais recentes do Python e a explosão combinacional do número de Pythons suportados. CPython está discutindo diferentes cadências de lançamento para 3.9, então 2 anos pode até ser mais longo do que alguns lançamentos podem ter de devs centrais.

Dito isso, não quero bloquear isso, mas principalmente garantir que expresse que não estou interessado em fazer isso.

(esperando por IronPython e Jython em algum ponto - qualquer outro que devamos oferecer suporte?)

Com certeza. @gaborbernat provavelmente sabe que eu diria isso - seria bom tê-los, mas tenho certeza de que as pessoas mais familiarizadas com a implementação estariam melhor posicionadas para fazer isso. No mínimo, em termos de suporte a longo prazo e, idealmente, também o trabalho de obter um bom suporte em primeiro lugar (IC, testes, etc).

primeiro, suporte de configuração ini (uma configuração ini global presente na casa do usuário),

Eu sou tendencioso - eu realmente gostaria que este fosse o TOML. :)

(Eu não processei isso completamente ainda, uma vez que tenho que ir a algum lugar - mas isso parece um grande objetivo geral!)

nós já não podemos realmente depender de pacotes adicionais por causa do recurso de interpretador cruzado, então eu não considero isso como uma grande desvantagem, e eu gostaria de ter uma maneira simples sem instalação / dependência de rodar ambientes virtuais (necessário quando as pessoas nos invocar a partir de pacotes de nós). Dado que não nos custa muito, a oferta além do zipapp parece barata.

prefira venv integrado: se o python de destino tiver venv, criaremos o ambiente usando isso (e, em seguida, realizaremos as operações subsequentes para facilitar outras garantias que oferecemos)

Não tenho certeza se entendi a razão disso. Parece que isso tornará a manutenção de virtualenv mais difícil e tornará os comportamentos mais difíceis de serem compreendidos pelos usuários finais. setuptools já está indo para o outro lado ao tentar absorver distutils vez de continuar a fazer o monkey patch.

@pganssle o escopo é diferente e o espaço do problema também. virtualenv é que freqüentemente os sistemas colocam restrições adicionais nos pacotes do sistema, então eles fazem o patch do venv embutido para aderir a elas. Seria difícil replicar tudo isso, consulte, por exemplo, # 1362.

FWIW Eu acho que usar o pacote venv para isolamento é a ideia certa, ele está embutido no interpretador real (ao invés de distutils que é apenas um módulo stdlib) para que possa fazer coisas muito mais limpas do que virtualenv pode.

O Virtualenv também não precisaria fazer o monkeypatch de nada, ele apenas usaria a API pública, o que deveria funcionar.

FWIW, eu recomendaria verificar meu antigo branch de reescrever virtualenv, ele já fazia muitas dessas coisas.

Eu provavelmente sugeriria que um sistema de plug-in não é muito útil para o virtualenv, no máximo, é provável que haja apenas um gancho, uma etapa de pós-criação e, mesmo assim, você provavelmente pode escapar apenas tendo uma lista de coisas para instalar.

TAMBÉM, você ainda pode depender de coisas "naturalmente" e ainda usar zipapps, você só precisa vender dentro do próprio zipapp. Eu recomendaria sair da opção reexecutar sob o alvo python, é uma coisa ruim e pode ser feita de forma muito mais limpa.

697 - PR mais antigo de @dstufft

PYTHONPATH = / t / path / to / virtualenv.whl python -m virtualenv

OTOH, provavelmente não deveríamos fazer isso de qualquer maneira - https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-direct-from- arquivo de roda

@pradyunsg então algum outro método para bootstrapping pip sem colocar a roda no caminho?

O pip de inicialização provavelmente está OK - é o que o virtualenv usa agora ¹ . Mas eu recomendo fortemente usá-lo apenas para pip, e não como um meio de executar o virtualenv em si.

¹ Mas eu evitaria qualquer funcionalidade complicada - usar uma roda no PATH para instalar o pip dessa roda é quase certo que está OK. Mas você pode ter problemas se, por exemplo, acessar a Internet usando essa roda, pois acho que o certifi precisa de seu pacote de certificado incorporado como um arquivo real (mas posso estar errado, isso nunca me causou um problema, mas eu sei get-pip.py extrai os certificados da roda explicitamente para tratar desse ponto.

Há alguma razão pela qual não enviamos pip como zipapp ? Isso evitaria essa necessidade, pelo que entendi, e zipapp é compatível com python 2.7 🤔

@gaborbernat você já experimentou? funciona? se a abordagem que você descreveu funciona no Windows, não tenho nenhuma preocupação inicial, mas provavelmente @uranusjr teria feedback. Meus únicos comentários estão de acordo com @dstuff, o que quer dizer - mais simples é melhor

Alguma razão para não enviarmos pip como zipapp?

Porque em certos casos, o pip não roda direto de um arquivo zip (ou de uma roda, é a mesma coisa), como falei acima. 99% (alerta - número composto) das vezes, funciona, mas às vezes o fato de que o pacote do certificado precisa ser um arquivo real é importante.

Provavelmente funcionaria bem agrupar o pip como um shiv , já que o shiv descompacta o zipapp antes de executá-lo, precisamente para evitar os casos extremos em que correr de um zip break. Ninguém, que eu saiba, tentou, no entanto.

Como de costume, os principais motivos pelos quais isso não aconteceu são:

1. Ninguém pensou nisso.
2. Ninguém teve tempo / motivação para o fazer.
3. A abordagem atual funciona bem, e há peixes maiores para fritar.

então, quaisquer outros métodos para bootstrapping pip sem colocar a roda no caminho?

Não acho que precisamos disso aqui - virtualenv está usando o pip wheel para instalar o IIRC por si mesmo, que deve funcionar bem. Como @pfmoore disse, a única coisa "extra" que get-pip.py faz é descompactar os certificados e fornecer um caminho para eles. Visto que o caso de uso do virtualenv não chegará à rede, não precisamos fazer nada de novo aqui.

A abordagem atual funciona bem, e há peixes maiores para fritar.

Isso, muito mais do que os outros IMO. Poderíamos, mas há questões mais impactantes para resolver. :)

Eu tive um PR em um ponto que construiu o pip como um aplicativo zip, ele funcionou, mas IIRC eu tive que fazer mudanças no pip para torná-lo totalmente funcional.

Isso pode ser um pouco complicado agora, já que o pip invoca a si mesmo como um subprocesso de si mesmo para o PEP 517. Não tenho certeza, mas definitivamente vale a pena explorar isso.

Neste ponto, o shiv (ou outra opção de extração automática) seria mais adequado para o pip do que tentar trabalhar o pip em um zip executável. Mas não acho que isso seja particularmente importante neste ponto. o assegurepip já segue a rota da roda no caminho, por que não fazer o mesmo. O bootstrapping alternativo de pip pode ser explorado depois de fritarmos todos os peixes maiores e, potencialmente, ser contribuído de volta para o stdlib.

O bootstrapping alternativo de pip pode ser explorado depois de fritarmos todos os peixes maiores

Parece um plano que já estamos seguindo. ;)]

Obrigado pelos links, com base no feedback, comecei alguns trabalhos iniciais em https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv. O plano é colocá-lo em uma forma de lançamento no próximo mês (e ter uma semana de revisão aberta antes disso). Com base no impacto da mudança, planejo fazer com que ele libere 20.0.0 .

1 para usar venv se existir. Isso tornaria o caso de uso do PyPy mais simples.

Então, a reescrita chegou a um estado em que me sinto confortável com as pessoas dando uma olhada e dando alguns comentários. Entre em contato comigo se tiver algum tempo livre para ajudar com isso; o plano é que seja lançado até o final do mês 🤞 Observação https://github.com/pypa/virtualenv/milestone/7 ainda precisa ser implementado, no entanto, a ideia central está lá.

PS. Criou um PR de feedback em https://github.com/pypa/virtualenv/pull/1481/

Solicitação de recurso: forneça um mecanismo para definir variáveis ​​de ambiente personalizadas, por exemplo, colocando um arquivo env.txt no diretório venv bin com o formato padrão:

VARNAME=value
OTHERVAR=othervalue

Acho que não entendo seu caso de uso. Como essas variáveis ​​de ambiente seriam usadas, definidas e quando?

Editar. NM. Vejo você expandido em https://github.com/pypa/virtualenv/issues/1124.

Uma pequena atualização; Consegui fechar a maioria dos problemas de bloqueio, além de dois que ainda precisam de algum cuidado: o teste inclui cabeçalhos + cache de chamadas de interrogação python com algum bloqueio aplicado sobre os dados do aplicativo, para que possamos criar ambientes virtuais em paralelo (para locais diferentes). No ritmo atual, posso chegar alguns dias atrasado ... mas definitivamente devo sair em 7 de fevereiro.

Qual é o nosso plano em termos de implementação? Teríamos um beta lançado antes do lançamento principal?

Sim, quero lançar algo na segunda-feira ... E então deixar provisoriamente uma semana para feedback, correções ... E então substituir master por reescrever e liberar.

Não estou 100% certo de que uma semana seria o suficiente e, com certeza, devemos comunicar através de vários canais que queremos que as pessoas experimentem o beta.

A palavra-chave lá estava provisoriamente . Estou otimista aqui, dado o esforço que fiz, não estou esperando grandes problemas, mas 🤷‍♂

virtualenv 20.0.0 beta1 está disponível .

Como a versão beta foi lançada, acho que esse problema atendeu ao objetivo. Vou encerrar e podemos discutir mais focados em questões específicas.