Pipenv: Use venv em vez de virtualenv se disponível

Acho que não, prefiro usar o comando virtualenv pessoalmente

Talvez seja possível fazer as duas opções coexistirem? Navegando casualmente pela fonte, não vejo nada especificamente acoplado ao Virtualenv, exceto o comando usado para criar o env. Virtualenv sempre pode ser o padrão, mas o usuário pode (por exemplo) passar --venv para criar .venv com python3 -m venv vez de virtualenv .

Honestamente, eu estaria contando apenas com o pipenv e não me importaria se o virtualenv ou o venv fosse usado, mas descobri que poderíamos aproveitar os recursos embutidos quando disponíveis.

Exorto @kennethreitz a reconsiderar seu comentário aqui. Usar python3 -m venv em vez de virtualenv é recomendado pela documentação padrão. Pessoalmente, estou desanimado de usar o pipenv porque ele usa o virtualenv. Eu só uso Python 3 e só uso venv hoje em dia.

@bulletmark Agora que o Pipenv delega quase todo o gerenciamento do Virtualenv para o Pew, é ainda mais difícil mudar, mas há planos para o Pew oferecer suporte a venv (berdario / pew # 67), então ainda há chance. Se o Pew pudesse fazê-lo funcionar, seria muito mais fácil (e faria mais sentido para mim, pelo menos) implementar o suporte para venv no Pipenv.

@uranusjr parece ótimo!

Eu pessoalmente nunca usei venv , daí minha apreensão quanto a isso. Tenho certeza que é bom, no entanto.

As coisas estão funcionando bem agora. Não há necessidade de mudar coisas que não estão quebradas.

Acabei encontrando este tópico porque meu sistema está quebrado.

Se você criar um ambiente com virtualenv no Python 3.X e, em seguida, atualizar para o Python 3.Y, o virtualenv será quebrado porque você sabe que não tem mais as bibliotecas compartilhadas de que o Python precisa. Usando venv você pode simplesmente executar python3 -m venv --upgrade .

Este seria um bom recurso.

Isso seria definitivamente bom e parece em linha com a direção do Python

Não usar o venv (e, em vez disso, usar o virtualenv) é um obstáculo total para mim - não posso usar o Pipenv. Não posso usar o virtualenv por causa de seu comportamento frustrante de copiar o binário python e ainda dependendo de bibliotecas compartilhadas - como dhouck descobriu acima para seu desgosto. Isso quebra o virtualenvs o tempo todo (sempre que o sistema python é atualizado, deixando o binário pendente) e copia o binário python desnecessariamente sem nenhum benefício.

Se pipenv é o futuro do Python, ele deve usar o venv no Python 3 por padrão (e avisar quando não estiver usando). É integrado ao Python 3 e é a ferramenta recomendada. É muito estranho que o Pipenv agora também seja uma ferramenta recomendada, mas não usa o venv.

O venv, por natureza, por ser parte do próprio Python, tem acesso aos componentes internos do Python, o que significa que pode fazer as coisas da maneira certa com muito menos hacks. Por exemplo, virtualenv tem que copiar o binário do interpretador Python para o ambiente virtual para induzi-lo a pensar que está isolado, enquanto o venv pode apenas usar um arquivo de configuração que é lido pelo binário Python em seu local normal para saber que deve agir como se estivesse em um ambiente virtual. Portanto, o virtualenv pode ser pensado da maneira certa, com a bênção e o suporte dos desenvolvedores Python.

Fonte: https://www.reddit.com/r/learnpython/comments/4hsudz/pyvenv_vs_virtualenv/

Comecei o berdario / pew # 173, mas não tive muito tempo para fazer progressos. Como mencionado acima, o Pipenv oferecerá suporte automaticamente assim que o Pew o fizer. Eu gostaria de alguma ajuda se alguém estiver interessado em trazer venv para Pipenv. O principal problema agora seria fazer os testes passarem.

Atualização rápida sobre o suporte venv: Isso não vai acontecer, pelo menos no futuro próximo. venv simplesmente não é bom o suficiente para fazer isso acontecer. Se você realmente se preocupa com isso, vá até o rastreador de bugs do virtualenv .

venv é a ferramenta recomendada para Python, e não está quebrada, como o virtualenv (re: copiar o binário do python então quebra quando as bibliotecas do python são atualizadas). O bug que você vinculou é sobre a combinação de venv e virtualenv, que não é o que estamos pedindo?

Infelizmente, é extremamente comum que as ferramentas se baseiem no virtualenv. Travis, por exemplo, usa o virtualenv para criar um ambiente de construção para você, conforme mencionado pelo relator original. É também a base do Pipsi, que é uma das formas recomendadas para instalar o Pipenv. Se venv não pode funcionar bem dentro dele. Está em muitos lugares sem você saber. O suporte do Venv estaria parcialmente quebrado e afetaria você de maneiras inesperadas se não funcionar bem com o virtualenv.

Eu entendo isso, mas neste ponto Pipenv é recomendado, e venv é recomendado, e eles estão em conflito. É um estado muito estranho.

Eu concordo totalmente que está em um estado estranho, é por isso que estou tentando consertar :) Não estou dizendo que não será consertado, mas precisa que mudanças upstream aconteçam primeiro, e não há nada que eu possa fazer até que eles acontecer. Eu posto o link não como uma desculpa para parar de trabalhar nele, mas para que as pessoas saibam onde devem se esforçar primeiro para ajudar a melhorar essa situação.

Talvez não seja muito louco manter este assunto em aberto, então?

Este é um problema de banco de dados, não um problema de pipenv.

venv simplesmente não é bom o suficiente para fazer isso acontecer. Se você realmente se preocupa com isso, vá até o rastreador de bugs do

Não é um problema de venv, mas de virtualenv. Eu postei algumas explicações no rastreador de problemas.
cc @uranusjr

Há uma palavra ao redor ->
Use o venv para criar um virtualenv primeiro e, em seguida, execute pipenv install . Por exemplo:

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

Apenas uma nota:

A solução alternativa acima geralmente funciona, mas pipenv run ... falha para mim porque não há activate_this.py em .venv/bin . Se for para acreditar no problema 21496 , não há planos de adicionar este arquivo ao venv. Portanto, mesmo que o pew conserte isso, o pipenv provavelmente ainda terá um problema.

Usando o virtualenv, é impossível usar o módulo tk do sistema no macOS. Mas usando o venv, é possível.
Desejo fortemente usar venv com pipenv (pode ser opcional).

Veja também: # 1416

Não quero parecer cínico, mas eu quero fortemente que alguém realmente escreva o código para apoiar isso, se eles realmente se importam tanto. Conheci várias pessoas dizendo que têm sentimentos “fortes” sobre isso, mas, pelo que sei, sou o único a fazer alguma coisa. E eu falhei. Isso não é tão simples quanto você pensa. Se você acha que pode fazer melhor, faça algo. Se você não quiser, por favor, pegue o que puder.

(kenneth e eu e provavelmente erin e nate também tentamos fazer isso com venv muito antes no projeto e também falhou por motivos de compatibilidade)

Isso seria bom, todos concordam. Adoraria vê-lo funcionando em plataformas e versões python.

Eu gostaria de apontar um outro motivo pelo qual o venv provavelmente seria uma escolha melhor do que o virtualenv:

um dos aspectos mais feios da implementação do virtualenv é que ele precisa ter sua própria cópia do módulo do site, que é usado para todos os virtuaisenvs, independentemente da versão do Python com a qual foram criados.
- de https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

Isso significa, por exemplo, que rlcompleter está desabilitado por padrão e isso é uma grande perda de usabilidade na minha opinião.

Além disso, como esse é um problema que afeta vários de seus usuários, sugiro mantê-lo aberto até que o problema seja corrigido, mesmo se você estiver esperando que algumas mudanças ocorram.

Novamente. Sabemos que seria melhor. Na verdade, não é possível. O que você acha que tem um impacto mais negativo, interrompendo completamente a funcionalidade para um grande segmento de usuários ou fazendo com que alguns usuários tenham que ativar os recursos readline?

Tenho certeza de que isso é inconveniente, também é inconveniente que só pareça haver pessoas exigindo isso e ninguém que vá oferecer uma implementação que funcione. Nós tentamos. Até que algo mude drasticamente, não temos planos de oferecer suporte a venv e, portanto, não temos planos de abrir esse problema.

@techalchemy Se bem entendi, pypa / virtualenv # 1095 é o lugar correto para discutir isso?

Parece certo, vi que o tox tem uma solução alternativa, então talvez funcionasse se alguém o transferisse

banco! que discussão ... se essa coisa de banco não for tão crucial, seria possível eliminá-los completamente junto com o virtualenv e deixar pipenv, venv e python andarem de mãos dadas, já que todos eles se recomendam?

As soluções de gerenciamento de dependência / ambiente virtual para python são um terreno muito selvagem no momento, e alguns sacrifícios precisam ser feitos, imho.

Isso pode assustar muitas pessoas que ainda não estão prontas para parar de usar o virtualenv, mas pode ser planejado para um dos próximos grandes lançamentos (se tecnicamente viável). A mudança é inevitável, é apenas uma questão de tempo.

@doganmeh Podemos abandonar o virtualenv por completo, construindo um produto equivalente para suportar apenas Python 3.3 ou superior, mas acho que seria mais fácil fazer esse outro projeto.

Apenas uma nota:

A solução alternativa acima geralmente funciona, mas pipenv run ... falha para mim porque não há activate_this.py em .venv/bin . Se for para acreditar no problema 21496 , não há planos de adicionar este arquivo ao venv. Portanto, mesmo que o pew conserte isso, o pipenv provavelmente ainda terá um problema.

Isso é mesmo necessário? Depois de criar um ambiente virtual com venv, você não precisa ativá-lo para usá-lo. Você simplesmente executa usando o binário python do diretório venv / bin.

FWIW, isso está relacionado (e o que me trouxe aqui): http://matplotlib.org/faq/osx_framework.html

Em um virtualenv , uma construção sem estrutura é usada mesmo quando o ambiente é criado a partir de uma construção de estrutura ( virtualenv bug # 54 , virtualenv bug # 609 ).

A solução é não usar o virtualenv, mas sim o venv do stdlib , que fornece funcionalidade semelhante, mas sem apresentar esse problema.

Descartar o suporte ao Python 2.7 / virtualenv para mim não parece uma ideia particularmente terrível, se permitir que pipenv conte com o stdlib de uma versão do Python cujo suporte não está prestes a expirar. Contanto que não corrompa nenhuma outra parte do conjunto de ferramentas pipenv que não seja facilmente corrigível para os mantenedores. Talvez até mova o suporte 2.7 para um branch / pacote separado?

Eu gostaria de poder contribuir com código real, mas não acho que tenho a experiência necessária para fazer isso ou o tempo: carranca: O melhor que posso fazer é adicionar à discussão no momento.

adicionando minha voz aqui; acabei de bater nisso por causa do mesmo problema que @dmtucker .

No momento, estou recorrendo a ignorar o pipenv completamente para este projeto quando estiver no meu mac, e fazendo o ambiente manualmente com o venv por enquanto.

+1 para usar o venv.
virtualenv tem muitos bugs wontfix .
pipenv completamente útil no Windows 10 com Python 3.7 da Windows Store ( bug virtualenv

virtualenv está mudando para o modelo venv - veja https://github.com/pypa/virtualenv/issues/1366 , que irá gerar pyvenv.cfg e todas as coisas boas, então isso deve ser resolvido por meio disso.

---------- Mensagem enviada ---------
De: Dan Ryan [email protected]
Data: segunda-feira, 26 de novembro de 2018, 14h39
Assunto: Re: [pypa / pipenv] Use venv em vez de virtualenv se disponível (# 15)
Para: pypa / pipenv [email protected]
Cc: Subscribed [email protected]

Parece certo, vi que tox tem uma solução alternativa, então talvez funcionasse se
alguém portou isso

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.