Pipenv: Como o pipenv conhece o virtualenv do projeto atual?

O nome do virtualenv é o nome do diretório raiz do projeto, mais o hash do caminho completo para a raiz do projeto. Isso garante que o nome seja único e previsível, desde que você não mova o projeto. (AFAICT, essa lógica de geração de nome é um detalhe de implementação em que não se deve confiar.)

Para instalar uma versão específica de um pacote, use a mesma sintaxe que usaria com pip e requirements.txt, por exemplo, pipenv install django==1.11.0 .

@uranusjr Isso significa que se eu renomear o diretório, o virtualenv do meu projeto será perdido. Isso é ruim. Pode ser um caso de uso comum renomear um diretório e os usuários podem cair nisso e se perguntar como seu ambiente parou de funcionar.

Eu sugeriria consertá-lo e fazer uma entrada no Pipfile, se isso for possível. Ou crie outro arquivo .pipenv para armazenar esses metadados em cada diretório do projeto.

O que você sugere ?

Obrigado por responder a ambas as perguntas!

Ei @ sachinjain024 , tivemos algumas discussões sobre o arquivo de metadados local, mas o consenso do mantenedor é que o pipenv não oferecerá suporte a isso no momento.

O caminho do diretório que identifica um projeto foi implementado desde o início porque os projetos com o mesmo nome, ou várias cópias do mesmo projeto, estavam causando a substituição acidental do estado do ambiente.

Na prática, descobrimos que muito menos pessoas tiveram problemas com o local ser parte do ambiente do que ter seu trabalho sobrescrito silenciosamente. Afinal, Pipenv é uma ferramenta de gerenciamento de implantação, então mover o diretório deve ser uma correção de um comando.

Obrigado @nateprewitt. Faz sentido pular rapidamente para uma implementação fácil. Suponha que eu renomeie um projeto em um estágio posterior, então isso significa que meu ambiente não existe.

Então, o que devo fazer nesta situação?

1. Reinicialize o ambiente porque eu já tenho o Pipfile que contém as informações dos pacotes, então será fácil reinicializar o env.
2. De alguma forma, renomeie o diretório virtualenv também
3. ???

O que você sugere neste caso? Só por curiosidade caso eu entre nessa situação no futuro.

Você pode usar pew cp para copiar facilmente o virtualenv existente, mas 1. seria a maneira mais “canônica” de fazer isso, eu acho.

@ sachinjain024 , sempre que precisar mover o diretório do projeto, você só precisará executar pipenv install para voltar ao estado de funcionamento. Isso criará um ambiente para você com o novo hash e reinstalará tudo, desde o lockfile de forma idêntica à instalação anterior com a qual foi criado.

Se você se pega fazendo isso com frequência, pode usar pew rm old_project-a3de90 para limpar.

Eu não recomendaria usar pew cp menos que você esteja modificando o ambiente virtual fora do pipenv. Nesse caso, acho que teríamos que considerar isso um cenário de "garantia anulada", porque existem todos os tipos de mudanças que não podemos contabilizar de forma confiável.

Obrigado @nateprewitt @uranusjr. Fechando este tíquete.

Esta é uma das piores ideias que surgiram de pipenv até agora. Aqui está o porquê:

Eu trabalho em uma empresa, onde Python é usado para automação de testes de vários projetos internos. Um testador geralmente funciona em uma dúzia deles. Por convenção, todo código de teste para um projeto reside em um diretório chamado tests . Isso significa que cada testador agora tem um monte de ambientes virtuais, todos chamados de ~/.local/share/virtualenvs/tests-hKjFddnZ - incrível! É da natureza humana esquecer de mudar de ambiente virtual, então, a cada poucos dias sou chamado para uma estação de trabalho diferente porque a pessoa naquela estação de trabalho pensa que instalou o pacote de que precisa, ela executou pipenv install , mas as importações no código não funcionam. Além disso, os ambientes virtuais órfãos se acumulam com o tempo, mas como todos eles têm nomes indefinidos, não há como saber se estou excluindo o ambiente que não está em uso ou o que está realmente sendo usado. Isso significa que em CI, criamos dezenas, senão centenas de ambientes virtuais diariamente. Não há como alguém rastrear ambientes com nomes essencialmente aleatórios, e há muitos deles, então temos que deletar todos eles pelo menos uma vez por dia. Pagamos um grande tributo em tempos de espera apenas por causa dessa decisão superinteligente de pipenv e alguém de nossa empresa, que decidiu usá-lo ...

Defina export PIPENV_VENV_IN_PROJECT=1 em sua configuração bashrc / shell.
(Ou mude seus scripts de shell para criar um venv em $ PROJECT / .venv e então
pipenv tem isso)
Na segunda-feira, 19 de março de 2018 às 6h28 wvxvw [email protected] escreveu:

Esta é uma das piores ideias que surgiram do pipenv até agora. Aqui está o porquê:

Eu trabalho em uma empresa, onde Python é usado para automação de teste de muitos
projetos internos. Um testador geralmente funciona em uma dúzia deles. Por
convenção, todo o código de teste para um projeto reside em um diretório chamado de testes.
Isso significa que cada testador agora tem um monte de ambientes virtuais, todos
chamado de algo como ~ / .local / share / virtualenvs / tests-hKjFddnZ -
impressionante! É da natureza humana esquecer de mudar de ambiente virtual, então,
a cada poucos dias sou chamado para uma estação de trabalho diferente porque a pessoa
naquela estação de trabalho pensa que instalou o pacote de que precisam, eles
executei pipenv install, mas as importações no código não funcionam. Não somente
que, os ambientes virtuais órfãos se acumulam ao longo do tempo, mas uma vez que todos
deles têm nomes indefinidos, não há como saber se estou excluindo
ambiente que não está em uso ou aquele que está realmente sendo usado. Isto
significa que em CI, criamos dezenas, senão centenas de ambientes virtuais
Diário. Não há como alguém rastrear ambientes que tenham
nomes essencialmente aleatórios, e há muitos deles, então temos que
exclua todos eles pelo menos uma vez por dia. Pagamos um alto preço em tempos de espera
apenas por causa desta decisão superinteligente feita por pipenv e alguém em
nossa empresa, que decidiu usá-lo ...

-
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/796#issuecomment-374211264 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner Então por que preciso de pipenv se vou criar um ambiente virtual manualmente?

O ambiente virtual é um trabalho independente. É coxo em todos os lugares e está quebrado no Windows (assume que no MS Windows, de todos os lugares, o diretório inicial padrão é chamado de "~"). Eu esperava que se alguém fosse refazer o PIP e o ambiente virtual, eles consertassem os erros óbvios de seus predecessores ... em vez disso, há essa bagunça multiplicada por uma camada de incompatibilidade.

Você está fazendo suposições erradas. Pipenv não refaz virtualenv ou pip. Baseia-se neles.

@uranusjr isso é um problema de compreensão de leitura. Eu sei muito bem o que pipenv faz, visto que passo muito mais tempo depurando seu código do que gostaria. Refazer o ambiente virtual e o PIP é o objetivo declarado do projeto. Que, em vez de consertá-los, decidiu usá-los "como estão" é outro grande erro da parte de pipenv , seguido pelo uso da biblioteca click , e a lista continua.

Refazer o ambiente virtual e o PIP é o objetivo declarado do projeto.

Onde alguém disse isso?

Eu também achei esse comportamento estranho, esperava que pipenv escolhesse um nome padrão para um diretório virtualenv e colocasse o diretório no diretório atual, semelhante ao modo npm usa node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Leia a documentação.

@uranusjr Eu li todos https://docs.pipenv.org e https://docs.pipenv.org/basics/ , ea menos que eu perdi, ele nunca menciona onde os virtualenv diretórios estão instalados, nem avisa a ninguém que renomear ou mover o diretório do projeto fará com que o diretório virtualenv tenha que ser recriado.

PIPENV_VENV_IN_PROJECT tem um nome confuso, já que pipenv não usa venv enviado na biblioteca padrão, ele usa virtualenv , que é um projeto diferente.

Estou apenas tentando fornecer feedback sobre as coisas em que tropecei enquanto me familiarizava com este projeto.

@Flimm, o objetivo é abstrair essas informações. Se você sabe como funcionam outras ferramentas que gerenciam o virtualenvs, já deve saber que mover a pasta do virtualenvs os torna impossíveis de encontrar. Se você não estiver familiarizado, provavelmente não irá cavar para encontrar isso em primeiro lugar.

Quanto à biblioteca de back-end que usamos para gerar virtualenvs e nomear variáveis ​​de ambiente, a primeira não é tão importante e a última é uma abreviatura amplamente aceita. Embora os detalhes sejam importantes, este não parece estar causando problemas a ninguém, e sua principal objeção parece baseada em você não ter certeza de qual backend usamos para colocar um executável Python em uma pasta. Se você encontrar bugs, por favor, relate-os. Nós realmente não vamos mudar as variáveis ​​de ambiente _só porque_.

A variável de ambiente está prontamente disponível nos documentos: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables então você provavelmente não leu todas elas se não viu isto

@techalchemy Por outras ferramentas, acho que você quer dizer algo como virtualenvwrapper . Passei anos sem usar virtualenvwrapper . Estou supondo que o número de desenvolvedores Python que estão familiarizados com o padrão node_modules de Nó / NPM é maior do que o número de desenvolvedores Python que estão familiarizados com virtualenvwrapper ou pipenv padrão de ocultar o diretório do ambiente. Mas é um palpite. Para quem não conhece nenhuma dessas ferramentas, acho que seria confuso não saber onde estão indo os arquivos instalados. Você salientou que isso só é explicado na seção avançada dos documentos na subseção de variáveis ​​de ambiente. Acho que deve ser explicado nos documentos muito antes disso. Talvez eu envie uma solicitação de pull.

Comentei sobre a referência confusa a venv vez de virtualenv na nomenclatura de PIPENV_VENV_IN_PROJECT em outra edição # 1919. Basta dizer que não mantenho bem a posição que acho que você pensa que tenho.

Em qualquer caso, a pergunta da edição original foi respondida. Não quero prolongar essa discussão, fique à vontade para dar a última palavra, se quiser.

Eu entendo que este é o público errado, mas já que esta discussão está acontecendo ... bem, eu não acho que node_modules foi uma inspiração para pipenv , e não para virtualenv também. Meu palpite pode estar historicamente incorreto, mas tendo que trabalhar com rbenv e virtualenv , posso dizer que virtualenv parece uma cópia incorreta ou talvez um protótipo inicial, que foi aprimorado em rbenv . Em ambos os casos, virtualenv é motivo de chacota em comparação com rbenv , e este é o motivo:

Ele copia pacotes para cada ambiente. Isso é estúpido, lento e confuso. É apenas uma má decisão de design, mas mais provavelmente apenas uma falta de decisão: simplesmente aconteceu assim porque alguém escreveu algum código para colocar esses pacotes em um diretório arbitrário. Além disso, não funciona realmente no Windows. A ponto de nunca ter sido realmente testado no Windows ... Uma coisa ridícula sobre ele é que ele testa o sistema operacional e, quando descobre que é executado no Windows, define o diretório inicial como ~ , esse padrão pode mais tarde ser substituído por algumas variáveis ​​de ambiente, mas se você estiver realmente tentando executar sua automação em um ambiente supervisionado e limpo ... virtualenv simplesmente nunca instalará os pacotes no mesmo diretório.

Então ... pipenv alega ser uma ferramenta para seres humanos, tipo requests ... eu acho? Então, deve melhorar os esforços imaturos feitos por seus antecessores ... bem, parece que esse seria o caminho a percorrer, se você quiser fazer um programa que faz a mesma coisa que os anteriores, mas melhor, certo ? E ainda, em vez de jogar fora o lixo de virtualenv , ele o usa como está. O wrapper só é diferente do programa empacotado porque não permite / torna mais difícil usar algumas das funções do programa empacotado ...

Na minha vida, já vi muitas tentativas de automação, que foi uma droga, mas vocês estão buscando as estrelas, vocês colocam todas aquelas avaliações imerecidas no seu site, antes mesmo de colocar qualquer informação útil. Mas você não cumpre a promessa. Na verdade, você simplesmente manipula a opinião pública, sem fazer nenhum trabalho real. E agora os programadores que precisam fazer automação precisam enfrentar outro mal, só porque alguém queria conseguir mais "curtidas" no GitHub ...

@wvxvw Na verdade, você está incorreto. virtualenv antecede rbenv em algo como cinco (quatro, veja abaixo) anos e, portanto, nunca pode ser inspirado por ele. Além disso, são coisas fundamentalmente diferentes, apenas alcançando um objetivo semelhante no final. O que você está procurando (ferramenta de gerenciamento de tempo de execução inspirada em rbenv) é o pyenv.

Também em relação ao virtualenv não estar no mesmo nível de outras ferramentas - você sabia que ele existe há dez (10) anos? Os requisitos de desenvolvimento de software mudam muito e as suposições feitas por ele estão gradualmente desatualizadas e ninguém se preocupou em substituí-lo. Você se importa o suficiente para avançar?

Eu entendo que todos merecem uma chance de falar, mas para entrar em uma discussão sem o mínimo de compreensão do assunto e começar a apontar o dedo imediatamente, isso é muito rude para os contribuidores dos sistemas de empacotamento Pipenv, virtualenv e Python como um todo. Por favor não faça isso.

Edit: Eu fiz algumas escavações. O lançamento inicial do virtualenv, 0,8, foi feito em 2007, enquanto o do rbenv (0,1) foi em 2011, então eles têm quatro anos de diferença, não cinco.

@wvxvw Eu só vi você oferecer insultos. Esse tipo de atitude não é bem-vindo aqui. Por favor, consulte nosso código de conduta antes de continuar postando.

Eu tive o mesmo problema depois de alterar o caminho do projeto e perder o mapeamento virtualenv original, então li este tópico. Em primeiro lugar, agradeço o trabalho da equipe pipenv. Acabei de receber algumas opiniões que gostaria de compartilhar sobre esta discussão:

1. O documento de fato deve apontar o mecanismo de mapeamento entre o caminho do projeto e env, pelo menos avisar os usuários que changing project path would cause unmapping the original env .

2. Será melhor se você puder definir manualmente o caminho para o env no Pipfile? Quero dizer, as pessoas podem ter alguns requisitos especiais para usar manualmente o mesmo env.

Apenas minhas opiniões para compartilhar com vocês.

Não está totalmente claro como usar o pipenv. Devo ter muitos ambientes virtuais para um projeto? Devo compartilhar os ambientes virtuais entre projetos? Como instalo uma versão diferente do python para um projeto específico com pipenv, se a versão do python só for necessária para esse projeto? Todo mundo está tão cheio de si neste tópico, assumindo um monte de coisas sobre outras pessoas, nunca tentando entender de onde os outros estão vindo. Quando li os elogios ao pipenv na página inicial, pensei que me ajudaria. Em vez disso, perdi 5 dias lutando com ele, e agora acho que volto a pyenv porque isso era pelo menos um pouco determinístico.

se você quiser usar vários ambientes para um projeto, use tox. Use pipenv para seu ambiente de desenvolvimento principal e tox para testes em várias versões de python.

@ashnur, você claramente precisa de algo para fazer. Em vez de espalhar negatividade entre um projeto de código aberto executado por voluntários, por que você não tenta contribuir com algo útil?

@uranusjr
este é o lugar onde o hash acontece?

Estou trabalhando em um projeto e preciso calcular o hash de um caminho.

@devxpy Sim, exatamente.

Acho que vocês deveriam colocar um tutorial básico de como configurar um virtualenv com pipenv algo muito básico porque quanto mais fácil for para as pessoas mais pessoas irão usá-lo, mas se causar confusão então mais pessoas podem não usar e podem procurar outros linguagens ou métodos para construir seus projetos

@uranusjr qual é a razão de o Pipenv não criar o virtualenv por padrão no diretório do projeto? A meu ver, isso resolveria o problema com ambientes órfãos quando o projeto é renomeado / movido / excluído. Além disso, seria menos confuso para as pessoas que (com alguma razão) esperam que funcione como o npm.

Há algum benefício em preferir essa abordagem além da tradição?

Simplesmente crie o diretório .venv antes do comando pipenv install. Uma opção —venv ou —dot-venv para instalar pipenv seria bem-vinda, na verdade :)

A partir de 09/10/2018, há outra maneira de fazer isso. Você pode adicionar um arquivo .venv contendo o caminho para o seu ambiente virtual. (Novo recurso sorrateiro!)

@andrewpeterprifer Porque costumávamos fazer isso e precisávamos mudar porque algumas pessoas rejeitaram fortemente. Precisamos escolher uma abordagem ou outra, e tenho que admitir que é um padrão melhor não colocar ambientes virtuais dentro do diretório do projeto.

ps Você (ou alguém) estaria interessado em escrever uma entrada faq sobre isso? Provavelmente levaria alguns parágrafos, mas eu ficaria mais do que feliz em explicar se alguém prometer dar um tempo para polir o texto e enviar um PR.

@uranusjr Estou super curioso por que é um padrão melhor. Sou relativamente novato em python e agora sinto que estou perdendo algo óbvio sobre as melhores práticas. :) Obrigado!

PS: Eu poderia escrever uma entrada no FAQ se você explicar por que as coisas são do jeito que são. ;)

A partir de 09/10/2018, há outra maneira de fazer isso. Você pode adicionar um .venv _file_ contendo o caminho para o seu ambiente virtual. (Novo recurso sorrateiro!)

@andrewpeterprifer Porque costumávamos fazer isso e precisávamos mudar porque algumas pessoas rejeitaram fortemente. Precisamos escolher uma abordagem ou outra, e tenho que admitir que é um padrão melhor não colocar ambientes virtuais dentro do diretório do projeto.

ps Você (ou alguém) estaria interessado em escrever uma entrada faq sobre isso? Provavelmente levaria alguns parágrafos, mas eu ficaria mais do que feliz em explicar se alguém prometer dar um tempo para polir o texto e enviar um PR.

Lamento topar ... Tenho essa mesma necessidade de mover pastas de projetos que possuem um ambiente virtual criado com pipenv.

Atualmente eu faço o seguinte e não tenho nenhum problema:

• Eu movo a pasta do projeto para onde eu quiser
• em C: \ Users \ user \ .virtualenvs eu deleto a pasta do venv associado ao projeto que acabei de mover
• Eu navego para o novo local da pasta do projeto via cmd e executo pipenv install (ou pipenv shell e, em seguida, pipenv sync)

Tudo funciona bem. Esta é uma prática ruim?

Em relação ao comentário de
Se for esse o caso, então não seria melhor se esse arquivo fosse criado automaticamente na pasta do projeto quando o ambiente virtual é criado inicialmente?

PS: Também estou disposto a escrever um FAQ

Na verdade, acho que a ideia de @ gioxc88 é boa, um virtualenv recém-criado pode gerar automaticamente .env arquivo na raiz do projeto e contém configurações de env como PATH . Isso tornará o ambiente mais transparente para os desenvolvedores e uma maneira mais conveniente de reconfigurar.

Vou tentar responder às suas perguntas juntos. A abordagem não é ruim (IMO; eu uso a mesma configuração também). No entanto, é mais fácil para um usuário desatento tropeçar.

Uma maneira de pensar nisso seria considerar colocar um projeto no controle de versão (digamos Git). Se o ambiente for criado na raiz do projeto, ele naturalmente estará na raiz do repositório. Pessoas como você e eu, que estamos acostumados com essa configuração, obviamente sabem que devemos adicionar uma regra em .gitignore (ou a configuração global de ignorar) para evitar que o diretório .venv seja verificado, mas um usuário desavisado não faria e poderia facilmente ser verificado no ambiente por acidente. Isso não é apenas ruim para o gerenciamento de projetos, mas (mais importante) fornece um vetor para ataques em potencial, expondo informações locais. Portanto, é uma regra geral para ferramentas de gerenciamento de projetos evitar colocar os arquivos gerados dentro do diretório do projeto . Pode ser normal (ainda não é a IMO ideal) fazer isso se você estiver projetando um ecossistema do zero (por exemplo, node_modules do NPM), mas definitivamente não é uma boa ideia para ferramentas construídas para um ecossistema com práticas comuns estabelecidas, como o caso da Pipenv.

Se um ambiente for gerado fora da raiz do projeto por padrão, há uma coisa a menos possível com que se preocupar ao publicar seu projeto (por exemplo, enviá-lo para o GitHub). Isso torna nossa vida (que prefere ambientes dentro do projeto) um pouco mais difícil, mas de uma perspectiva de risco, o pior que pode acontecer é mover acidentalmente o projeto e quebrar o ambiente, ou esquecer de remover um ambiente quando um projeto é removido . Ambos são muito mais facilmente recuperáveis ​​do que enviar acidentalmente suas informações de ambiente potencialmente confidenciais para o GitHub.

O recurso de arquivo .venv ainda é bastante novo (lançado apenas alguns dias atrás) e ainda estamos explorando maneiras de utilizá-lo da melhor maneira. Ele ainda tem o mesmo problema de um diretório .venv , mas espero que não seja tão ruim. Eu realmente gosto do recurso e definitivamente espero que possamos usá-lo para melhorar a experiência do usuário, mas ainda há muito a ser considerado aqui.

Oi. Para mim, o diretório .venv (recurso antigo) e o arquivo .venv (novo recurso) estão ok, mas eu ficaria muito grato por ter uma opção no comando pipenv install.

Algo como:

pipenv install

Instalaria em ~/.local/

pipenv install --venv

Seria instalado no diretório $PWD/.venv

pipenv install --venv-dir /my/custom-path

Seria instalado em /my/custom-path .

Se você deseja um novo recurso, proponha-o adequadamente fazendo uma proposta de melhoria para ~/.peeps . Não faça propostas de aprimoramento espalhadas aleatoriamente em torno de vários problemas, não é rastreável.

@uranusjr obrigado pela resposta detalhada! Apenas para satisfazer minha curiosidade, que tipo de informação local (potencialmente sensível) poderia ser exposta por um check in python venv? Eu concordo que é irritante se node_modules for verificado, mas normalmente isso não conteria nenhuma informação local.

Os ambientes virtuais Python contêm vários scripts de shell (por exemplo, activate ). Muitas pessoas os modificam para adicionar variáveis ​​de ambiente para especificar senhas de banco de dados, caminho para outro arquivo de configuração, etc. Modificar scripts em ambientes virtuais é contra a prática recomendada, mas as pessoas fazem isso mesmo assim (e ficam na defensiva quando você lhes diz para parar de fazer isso -experiência pessoal).

Além disso, você está certo, node_modules provavelmente não contém informações confidenciais. Esse é outro benefício quando você constrói um ecossistema do zero. Os ambientes virtuais Python infelizmente foram inventados muito antes de ser um problema comum (naquela época você já é um guru, se usar o VCS).

Cheguei aqui enquanto tentava entender como o pipenv conhece o virtualenv certo:)

Obrigado pessoal por essa discussão. Provavelmente, pode ser uma boa ideia especificar na página principal (por exemplo, aqui ) que renomear o caminho do projeto quebra o mecanismo padrão de vinculação virtualenv.

Todas as páginas de documentação estão abertas para contribuições. Não peça coisas, faça :)

Eu irei!

@uranusjr Isso significa que se eu renomear o diretório, o virtualenv do meu projeto será perdido. Isso é ruim. Pode ser um caso de uso comum renomear um diretório e os usuários podem cair nisso e se perguntar como seu ambiente parou de funcionar.

Eu sugeriria consertá-lo e fazer uma entrada no Pipfile, se isso for possível. Ou crie outro arquivo .pipenv para armazenar esses metadados em cada diretório do projeto.

O que você sugere ?

Obrigado por responder a ambas as perguntas!

obrigado por fazer a pergunta. eu também encontro o mesmo problema,

Se você inicializou pipenv em um diretório errado e tem que utilizar o diretório virtualenv do diretório correto, você pode obter o caminho virtualenv fazendo pipenv --venv e mover PIpfile e Pipfile.lock para o diretório correto.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv no diretório correto e deve funcionar corretamente.

Percebi hoje que se houver um pipfile no diretório pai, pipenv ignora a variável de ambiente export PIPENV_VENV_IN_PROJECT=1 e instala um venv no diretório pai. Este é o lançamento 2018.11.26 . Se você remover o pipfile do diretório pai, pipenv funcionará conforme documentado.