Virtualenv: Incluir scripts de biblioteca padrão nos scripts do virtualenv

Isso ainda ocorre depois de fazer o rehash do pyenv?

O que o shim executa quando executado antes ou depois do pyenv rehash?

Tenho a sensação de que isso tem algo a ver com pyenv.

Isso ainda ocorre depois de fazer o rehash do pyenv?

sim.

O que o shim executa quando executado antes ou depois do pyenv rehash?

Como system Python é selecionado para o qual o pacote apt com 2to3 não está instalado, ele diz

pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
<list>

em ambos os casos.

Tenho a sensação de que isso tem algo a ver com pyenv.

pyenv é irrelevante. O comportamento esperado era que o segundo which retornasse o calço de virtualenv como faz para python . O bug é que virtualenv não cria um. (Eu pensei que isso era óbvio. Provavelmente não.)

Ah, ok... O que é PATH após a ativação?

(Não estou em uma máquina onde posso tentar reproduzir isso agora)

(test) vmuser<strong i="5">@ubuntuvm</strong>:~$ echo $PATH
/home/vmuser/test/bin:/home/vmuser/.rbenv/shims:/home/vmuser/.rbenv/bin:/home/vmuser/.pyenv/shims:/home/vmuser/.pyenv/bin:/home/vmuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vmuser/.rvm/bin
(test) vmuser<strong i="6">@ubuntuvm</strong>:~$ ls /home/vmuser/test/bin
activate       activate_this.py  pip     python3
activate.csh   activate.xsh      pip3    python3.6
activate.fish  easy_install      pip3.6  python-config
activate.ps1   easy_install-3.6  python  wheel

Como solução alternativa, você pode usar python -m lib2to3 dentro de seu virtualenv, com funcionalidade equivalente.

/cc outros @pypa/virtualenv-committers se eles acharem que adicionar scripts da biblioteca padrão ao virtualenv ao criá-los é uma boa ideia.

Eu sou ambivalente.

Estou -0,5. É uma desordem extra que não foi sinalizada como um problema até agora, então presumo que a necessidade seja rara. Não estou convencido de que o Python 2 se aproximando do EOL faça diferença aqui. Os scripts extras também não estão em PATH em um ambiente não virtual no Windows, portanto, não é como se a expectativa de que eles estejam presentes seja universal.

Eu acho que isso deve funcionar como abordagem geral. Todos os aplicativos no ambiente host devem estar disponíveis no nível do ambiente virtual.

Não estou convencido de que o Python 2 se aproximando do EOL faça diferença aqui.

+1

Essa não é a minha preocupação aqui também. :)

Os scripts extras também não estão em PATH em um ambiente não virtual no Windows

Oh. Eles não estão no diretório Scripts/ ? Meu entendimento era que os instaladores atuais do python.org adicionam esse diretório ao PATH e, portanto, eles podem ser executados.

Todos os aplicativos no ambiente host devem estar disponíveis no nível do ambiente virtual.

Uhm... "aplicativos" é um pouco vago aqui - você está se referindo aos scripts ou algo mais? Você poderia por favor esclarecer o que quer dizer?

Observe que, se fizermos isso, sou um forte -1 em incluir todos os scripts do ambiente host de qualquer maneira e ambivalente em incluir aqueles que são apoiados pela biblioteca padrão.

Oh. Eles não estão no diretório Scripts/?

Não, tudo o que está em Scripts são wrappers de ponto de entrada para bibliotecas instaladas (pip, easy_install e wheel em uma instalação básica). Olhando um pouco mais adiante, 2to3.py está em Tools/scripts (junto com um grupo bastante misto de mais de 60 outros scripts), mas esse diretório não é colocado em PATH , mesmo se o usuário seleciona "Adicionar Python ao seu PATH".

Observe que, se fizermos isso, sou um forte -1 em incluir todos os scripts do ambiente host de qualquer maneira e ambivalente em incluir aqueles que são apoiados pela biblioteca padrão.

No mínimo, eu diria que não devemos adicionar mais ao PATH do que uma instalação básica. O que significa que, mesmo que façamos isso, não o faremos no Windows.

pradyunsg mudou o título Incluir scripts de biblioteca padrão no bin do virtualenv/ Incluir scripts de biblioteca padrão nos scripts de virtualenv 2 horas atrás

Apenas observando que esta é uma pequena mudança de escopo. O OP estava especificamente interessado apenas em 2to3 , e em particular que a ativação de um virtualenv não sombreava o sistema 2to3 . Se isso é importante, não posso comentar (dado que argumentei para que isso não aconteça no Windows, não tenho experiência relevante no Unix para dizer se sinto que isso é um problema). Mas sem saber quais outros scripts são "scripts de biblioteca padrão", não posso comentar se esse é um ponto significativo.

Hmm, pyvenv é provavelmente outro "script de biblioteca padrão", e tenho certeza de que não queremos ocultar a versão do sistema com um que execute venv de um ambiente virtualenv (pois isso causa complicações sem nenhum benefício prático).

O OP estava... interessado... em particular que a ativação de um virtualenv não sombreava o sistema 2to3.

(Não tenho certeza do que essa frase coloca na minha boca, pode ser interpretada nos dois sentidos.)

Para maior clareza, estou pedindo virtualenv para criar um calço para 2to3 .

(Deixe-me editar o post original com o comportamento esperado, vejo que omitir está causando confusão.)

(Deixe-me editar o post original com o comportamento esperado)

Feito. Também esclareci por que o usuário esperava que estivesse em PATH .

Não tenho certeza do que essa frase coloca na minha boca

Desculpe por deturpar seus comentários e obrigado pelo esclarecimento! (Parece que entendi corretamente o que você estava pedindo, apenas reafirmei mal...)

Também esclareci por que o usuário esperava que estivesse no PATH.

O link que você citou é um pouco confuso. O usuário parece ter um processo que funciona em trusty e xenial, mas não em bionic. Não está claro para mim por que esse seria o caso se o problema estiver no virtualenv. (Observação: isso é uma digressão - independentemente, é claramente o caso de virtualenv não copiar 2to3.py , portanto, a discussão sobre se devemos é válida, mesmo que o problema original seja mais sutil).

Estou pedindo virtualenv para criar um shim para 2to3.

Observe que nunca criaremos um calço. Tudo o que faríamos é copiar o script 2to3.py . Se um shim for necessário (isso é uma coisa pyvenv, eu acho), então não seríamos nós que lidaríamos com isso.

Não, tudo o que está em Scripts são wrappers de ponto de entrada para bibliotecas instaladas (pip, easy_install e wheel em uma instalação básica).

Ooooooooooooo. OK.

Apenas observando que esta é uma pequena mudança de escopo.

Eu não acho que 2to3 seja um floco de neve especial - se adicionarmos isso, espero que alguém apareça pedindo o resto. Devemos fazer isso totalmente ou não fazer nada. Ficar preso no meio do caminho não é algo que gostaríamos aqui.

(Eu odeio a interface do usuário móvel)

É "especial" porque é apoiado pela biblioteca padrão E está em PATH para uma instalação padrão do Linux.
Na verdade, não existem muitas outras ferramentas como esta. Além de 2to3 , são apenas pydoc , idle e pyvenv :

$ ls ~/.pyenv/versions/3.6.9/bin
2to3          easy_install-3.6  idle3.6  pip3.6  pydoc3.6  python3.6         python3.6m         python-config  virtualenv
2to3-3.6      idle              pip      pydoc   python    python3.6-config  python3.6m-config  pyvenv
easy_install  idle3             pip3     pydoc3  python3   python3.6-gdb.py  python3-config     pyvenv-3.6

(também python-config que já está sendo redirecionado)

Ah, obrigado pelo esclarecimento @native-api! Muito apreciado. Junto com a explicação do @pfmoore de como esse é um problema que não é do Windows, isso ajuda meu entendimento. :)

Ainda estou ambivalente em incluí-lo.

Além de 2to3, é apenas pydoc, idle e pyvenv

Gostaria de saber quem escolheu essa lista. É especificamente pyvenv? Ubuntu (bash no Windows e uma imagem docker com python3 instalado) não parece ter 2to3 por padrão, embora a imagem do docker Python tenha os mesmos binários que você mencionou (mais pip, easy_install e wheel, que vêm de pacotes instalados). Parece um pouco dependente da distribuição :-( Pelo menos a lista de binários relevantes parece consistente.

BTW, como eu disse acima, mesmo que façamos essa alteração, aconselho vivamente a não incluir o pyvenv.

Ubuntu (bash no Windows e uma imagem docker com python3 instalado) não parece ter 2to3 por padrão

Isso porque no Ubuntu, 2to3 é movido para um pacote separado:

$ apt-file search 2to3 | grep -E '/2to3[^/]*$'
2to3: /usr/bin/2to3
<...>
python2.7: /usr/bin/2to3-2.7
<...>

Por "instalação padrão do Linux", eu quis dizer a lógica que é intrínseca ao script de compilação do Linux do Python, sem a interferência das distros - por exemplo, se você instalar a partir da fonte (que é o que pyenv faz).

Eu poderia pegar isso e vou tentar trabalhar nisso.

Observe que isso substituiria nosso hack atual de adicionar pydoc como parte do script de ativação.