Pipenv: Última dependência padrão sendo marcada como local e editável

Criado em 1 out. 2020 · 9Comentários · Fonte: pypa/pipenv

Verifiquei a documentação de diagnóstico para problemas comuns. Descrevi meu fluxo de trabalho (possivelmente falho) nas etapas para reproduzir a seguir. Eu estive me preocupando com isso por algumas semanas, culpando a mim mesma, e adoraria que isso fosse um bug de mim.

Descrição do problema

O último pacote externo listado na seção padrão de Pipfile.lock está incorretamente sendo marcado como local e editável

Resultado esperado

O último pacote externo listado ainda é fornecido pelo pypi

Resultado atual

Meu Pipfile.lock inclui esse diff, o que interrompe o CI e outros usuários por razões óbvias:

             "version": "==1.25.10"
         },
         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },
     "develop": {

Etapas para replicar

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
flake8 = "3.8.3"
pytest = "5.4.3"
pytest-cov = "2.10.0"
termcolor = "1.1.0"

[packages]
mycli = {editable = true, path = "."}

[requires]
python_version = "3.7"

(mycli tem um setup.py para facilitar a criação de um ponto de entrada para o clique do python e define dependências não dev)

O projeto é um utilitário CLI e nós clonamos o repositório e instalamos via:
PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy

Como um desenvolvedor adicionando uma nova dependência, edito o setup.py e executo:
pipenv lock

Isso gera um arquivo Pipfile.lock que inclui minha nova dependência, mas também uma última dependência padrão malformada (tive o problema com vários pacotes que estão perto do final do alfabeto nessa posição, especificamente wrapt e zipp )

Consigo solucionar o problema e gerar um Pipfile.lock correto ao:
rm -rf Pipfile.lock .venv
e
pipenv lock

Estou omitindo propositalmente a saída de pipenv --support porque o aplicativo no qual estou trabalhando é proprietário e me preocupo em vazar detalhes de nosso ambiente (ou de nossa equipe de segurança gritando comigo: rindo :). Se houver trechos específicos que eu possa limpar e fornecer, ficaria feliz em fazê-lo, só não quero limpar a coisa toda logo de cara.

Obrigado por ler e de novo, espero que eu esteja apenas sendo burro.
Obrigado!

Type Vendored Dependencies

Fonte

gregflynn

👍3

Comentários muito úteis

Como @jmehnle e @patelamol comentaram, estou tendo um problema semelhante com alguns de meus pacotes neste caso

       "zipp": {
            "editable": true,
            "path": "."
        },

Minha solução foi editar manualmente o bloqueio do pipfile, que não é seguro / íntegro para a versão mais recente

"zipp": {
            "hashes": [
                "sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
                "sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
            ],
            "version": "==3.2.0"
        }

Eu me pergunto se há uma atualização pipenv em breve com esta correção

ch3ck em 9 out. 2020

👍2

Todos 9 comentários

@patelamol e posso reproduzir isso com pipenv 2020.08.13.

jmehnle em 1 out. 2020

😕1 👍1

Eu experimentei esse bug em todas as versões mais recentes até 2018.11.26 . Portanto, 2018.11.26 não tem esse problema.

patelamol em 2 out. 2020

👍2

Como @jmehnle e @patelamol comentaram, estou tendo um problema semelhante com alguns de meus pacotes neste caso

       "zipp": {
            "editable": true,
            "path": "."
        },

Minha solução foi editar manualmente o bloqueio do pipfile, que não é seguro / íntegro para a versão mais recente

"zipp": {
            "hashes": [
                "sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
                "sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
            ],
            "version": "==3.2.0"
        }

Eu me pergunto se há uma atualização pipenv em breve com esta correção

ch3ck em 9 out. 2020

👍2

@gregflynn @patelamol Então, esse problema existe no branch master? Não consigo reproduzir com os passos dados

frostming em 27 out. 2020

@gregflynn @patelamol Então, esse problema existe no branch master? Não consigo reproduzir com os passos dados

Certamente! Não executei o pipenv do github antes e não vi as instruções no README, então serei prolixo sobre as etapas:

git clonado
pyenv virtualenv 3.7.9 pipenv && pyenv local pipenv && pip install -e .
verificação:
`` `
$ pipenv --version
pipenv, versão 2020.8.13

$ ~/.pyenv/versions/pipenv/bin/pipenv --version 
pipenv, version 2020.8.13.dev0
```

fez um novo venv com 2020.8.13
adicionou stockquotes == 2.0.0 ao meu setup.py
correu ~/.pyenv/versions/pipenv/bin/pipenv lock
Sem dados, vendo o erro com

         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },

@frostming obrigado pela sugestão e dando uma olhada,

gregflynn em 27 out. 2020

@gregflynn

fez um novo venv com 2020.8.13

Esta etapa é crítica para reproduzir o bug? Eu crio com o mestre Pipenv e não consigo reproduzir. Uma imagem docker seria de grande ajuda, se possível

frostming em 28 out. 2020

@gregflynn
fez um novo venv com 2020.8.13
Esta etapa é crítica para reproduzir o bug? Eu crio com o mestre Pipenv e não consigo reproduzir. Uma imagem docker seria de grande ajuda, se possível

Olho bom, mas fiz as seguintes alterações e ainda fui capaz de reproduzir com a versão master mais recente. Para a etapa 4, atualizei meu script de instalação:

-PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
+PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 $HOME/.pyenv/versions/pipenv/bin/pipenv install --deploy

e ainda tenho:

         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },

Fico feliz em tentar mais coisas! obrigado

gregflynn em 28 out. 2020

Ah, consegui reproduzir! Não percebi que o fator crítico é VENV_IN_PROJECT.

frostming em 29 out. 2020