Pipenv: 26/11/2018: pipenv emite erros pythons ao criar um virtualenv

Parece que /usr/local/bin/pythonz não é mais um caminho válido.

Hmm. Deveria ter sido? Nunca usei o pythonz diretamente. Achei que fosse apenas uma dependência do pipenv que ele gerenciava quando instalei o pipenv.

Para começar, acabei de desinstalar e reinstalar o pipenv 2018.11.26 e ainda estou tendo o problema.

Você pode fornecer a saída de pipenv --support ? E para confirmar, não, não deveria ter sido

Oh, nvm acabei de ver sua mensagem. Só quero confirmar que não há uma versão não autorizada do pipenv em seu caminho em algum lugar. Você pode verificar which pipenv e python -m pipenv --version

$ which pipenv
/usr/local/bin/pipenv

python -m pipenv --version retornou No module named pipenv porque tenho Python 2 e Python 3 instalados via Homebrew e python executa Python 2.7. Por recomendação anterior aqui, instalei o pipenv no Python 3. Então, substituí em python3 e obtive:

$ python3 -m pipenv --version
pipenv, version 2018.11.26

Obrigado!

Ah ok. E sim, o bug faz sentido. Vou apenas marcar o upstream e garantir que seja corrigido

Alguma palavra sobre quando uma correção será lançada para isso? Estou tendo esse problema, ele está me impedindo de instalar os requisitos do pipenv. Eu tentei a solução alternativa do @commandtab sem essa sorte.

Eu não posso começar pipenv ao trabalho em tudo com a versão atual.

$ which pipenv
/Users/josh/.pyenv/shims/pipenv

$ python -m pipenv --version
pipenv, version 2018.11.26

Tentei instalar com python3.7 do homebrew e deu o mesmo problema.

Parece que não há urgência aqui, ou que não é um grande problema. Estou faltando alguma coisa ou o pipenv está completamente quebrado com a versão atual?

A versão atual com certeza me parece confusa. Outra solução temporária que vi em um problema anterior foi passar especificamente um caminho python assim:

pipenv --three --python=`which python3`

Tenho feito isso com sucesso por enquanto: fazer caretas:

Essa solução alternativa não estava funcionando para mim. Tive que fazer o downgrade para 2018.10.13 e, em seguida, usar a solução alternativa nesse tópico :

pipenv install -d --python=$HOME/.pyenv/versions/3.7.1/bin/python

Até onde eu posso dizer, pipenv está completamente quebrado desde outubro.

@techalchemy Alguma palavra sobre uma correção de tag upstream? A criação do pipenv virtualenv ainda requer soluções alternativas para a chamada.

Obrigada ❤️

Isso foi um pouco difícil com todas as outras correções que precisavam ser integradas, mas acho que o CI passará agora e isso será corrigido com # 3330 - desculpe pelo problema

Ah ok. E sim, o bug faz sentido. Vou apenas marcar o upstream e garantir que seja corrigido

O problema ainda persiste, qualquer ideia de quando essa correção será lançada.

Mesmo problema aqui.

Pode confirmar que a solução alternativa do @ command-tab ainda funciona.

Isso definitivamente ainda acontece com homebrew pipenv e python ... meio que surpreso que não haja um teste para cobrir isso, vendo há quanto tempo esse problema existe ...

Também posso confirmar que esse problema ainda está acontecendo, apesar do problema do GitHub ter sido resolvido.

Os mantenedores precisam que um novo problema seja criado?

Mesmo problema com o Ubuntu 18 LTS instalado no subsistema Windows para Linux.

A solução alternativa funciona para mim.

@techalchemy esse problema ainda parece existir. Você pode reabri-lo ou deixar claro que deseja que um novo problema seja criado?

Obrigado.

Mesmo problema com o Ubuntu 18 LTS instalado no subsistema Windows para Linux.

o mesmo aqui

@techalchemy por favor dê uma olhada novamente

O mesmo problema aqui em macOs Mojave e python 3.7

Eu também:

• Catalina
• Python 3.7.

Tudo funciona bem depois de comentar esta linha no meu Pipfile:

[requires]

#python_version = "3.7.4"

Eu também:

• Catalina
• Python 3.7.

Tudo funciona bem depois de comentar esta linha no meu Pipfile:

[requires]

#python_version = "3.7.4"

ahhhh isso funcionou para mim, obrigado!

@JarredStanford @edsu
Isso funcionou para mim também no WSL no VSCode (não tentei um shell externo, pois funcionou bem para um projeto diferente).

@ command-tab
Adicionar "--python = which python3 " também funcionou. Não tentei adicionar "--três" e parece não ser necessário para meu caso de uso / versão.

Depois de obter as duas soluções alternativas e consegui fazê-las funcionar, removi-as e tentei uma terceira vez para garantir que o ambiente ainda estava causando um problema (narrador: era).

@techalchemy
Estou pensando que isso pode não estar "totalmente corrigido" no 3330? Pode ser um problema tangencial que causa os mesmos sintomas. No meu caso, estou usando WSL e me perguntando se 'python3' e 'python3.exe' ambos em meu caminho WSL parece suspeito.

Você acha melhor eu abrir um novo problema, quer que eu execute diagnósticos adicionais ou algo mais?

Estou usando wsl2 com arclinux (manjaro)
Parece que o pipenv está chamando o python nas janelas do env do host para instalar
então precisamos definir onde encontrar o python com:
pipenv --python=<PATH_TO_PYTHON>
ou
pipenv --python=which python3

funciona para mim.

Pode confirmar que isso acontece sob WSL com Ubuntu 18.04 LTS. Parece que o pipenv está procurando um interpretador python em vez de usar aquele sob o qual ele está sendo executado e, ao fazer isso, está percorrendo o PATH na ordem inversa. Tenho vários ambientes Python instalados e sempre que removo manualmente um do PATH, pipenv encontrará um diferente e reclamará dele.

Estou vendo o mesmo problema no WSL com Ubuntu 18.04 LTS. pipenv install --python $(which python3) funciona, mas quando eu subsequentemente faço pipenv shell , ele não consegue encontrar as dependências que deveria ter baixado.

Também fui afetado, usando WSL 1 e Ubuntu 18.04. A solução alternativa --python $(which python) funciona.

O motivo da última parte da exceção, ou seja, este bit:

  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/utils.py", line 68, in get_python_version
    combine_stderr=False, write_to_stdout=False)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 314, in run
    write_to_stdout=True
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 162, in _create_subprocess
    sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))
TypeError: write() takes exactly one argument (3 given)

... é porque há um bug na chamada para imprimir um erro ao lidar com a primeira exceção. Esse bug parece já ter sido corrigido no mestre em janeiro de 2019 - https://github.com/pypa/pipenv/commit/574fe7308d9ac81d64da954722f35c9eee0dd467#diff -a59595db75020aeb9f688d6a0b4818e6L162. Mas como a versão mais recente do pipenv é 2018.11.26, imagino que a maioria não tenha uma versão fixa.

Pode-se remendar manualmente. Abra /usr/local/lib/<your-python-version>/site-packages/pipenv/vendor/vistir/misc.py , navegue até a linha 162 e altere isso:

sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))

... para isso:

sys.stderr.write(f"Error {exc} while executing command " + " ".join(cmd._parts))

Agora você obterá um relatório de exceção mais preciso. No meu caso, o problema tem a ver com o pipenv baseado em WSL Linux detectando instalações Python baseadas no Windows e tendo problemas para executá-las, o que é óbvio:

Error [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe' while executing command /mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe -c import sys; print(['Traceback (most recent call last):\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/contextmanagers.py", line 150, in spinner\n    yield _spinner\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 314, in run\n    write_to_stdout=True\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 160, in _create_subprocess\n    combine_stderr=combine_stderr)\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 134, in _spawn_subprocess\n    return subprocess.Popen(cmd, **options)\n', '  File "/usr/lib/python3.6/subprocess.py", line 729, in __init__\n    restore_signals, start_new_session)\n', '  File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child\n    raise child_exception_type(errno_num, err_msg, err_filename)\n', "OSError: [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe'\n"]

Para usuários WSL, acredito que o problema pode ser aliviado garantindo que quaisquer requisitos em sua versão Python em Pipfile sejam _exatamente_ correspondidos por uma instalação Python baseada em Linux, por exemplo

[requires]
python_version = "3.6.8"  # Make sure this exactly matches an installed version, or remove it.

Espero que isto ajude.

Não tenho certeza do quanto isso ajuda, mas excluir o Pipfile, executando pipenv lock , e então colocar o conteúdo do Pipfile antigo de volta e executar pipenv install funciona para mim permanentemente.