Pipenv: 2018.11.26: pipenv выдает ошибки pythons при создании virtualenv

Кажется, /usr/local/bin/pythonz больше не является допустимым путем.

Хм. Должно ли это когда-нибудь быть? Я никогда не использовал pythonz напрямую. Я думал, что это просто зависимость от pipenv, которую он управлял, когда я установил pipenv.

Я просто удалил и переустановил pipenv 2018.11.26, и проблема все еще не устранена.

Можете ли вы предоставить результат из pipenv --support ? И чтобы подтвердить, нет, этого не должно было быть

О, nvm только что увидел ваше сообщение. Я просто хочу подтвердить, что на вашем пути где-то нет мошеннической версии pipenv. Можете ли вы проверить which pipenv и python -m pipenv --version

$ which pipenv
/usr/local/bin/pipenv

python -m pipenv --version вернул No module named pipenv потому что у меня Python 2 и Python 3 установлены через Homebrew, а python запускает Python 2.7. Согласно предыдущей рекомендации, я установил pipenv под Python 3. Поэтому я заменил python3 и получил:

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

Благодаря!

Ах хорошо. И да, ошибка имеет смысл. Я просто помечу его вверх по течению и исправлю.

Есть какие-нибудь сведения о том, когда будет выпущено исправление для этого? У меня возникла эта проблема, из-за которой я не могу установить требования pipenv. Я пробовал обходной путь

Я не могу pipenv работать вообще с текущей версией.

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

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

Я попытался установить с помощью python3.7 из доморощенного и той же проблемы.

Похоже, здесь нет срочности или это не большая проблема. Мне что-то не хватает, или pipenv полностью не работает в текущей версии?

Текущий выпуск кажется мне безнадежным. Другой временный обходной путь, который я видел в прошлой проблеме, заключался в том, чтобы специально передать путь python следующим образом:

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

Пока что делаю это с успехом: grimacing:

Этот обходной путь у меня не работал. Мне пришлось перейти на 2018.10.13 а затем использовать обходной путь в этом потоке :

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

Насколько я могу судить, с октября pipenv полностью сломан.

@techalchemy Есть слова об исправлении тега восходящего потока? Создание pipenv virtualenv по-прежнему требует обходных путей для вызова.

Спасибо ❤️

Это было немного грубо со всеми другими исправлениями, которые необходимо было интегрировать, но я думаю, что CI пройдет сейчас, и это будет исправлено с помощью # 3330 - извините за проблемы

Ах хорошо. И да, ошибка имеет смысл. Я просто помечу его вверх по течению и исправлю.

Проблема по-прежнему сохраняется, есть какие-либо идеи, когда это исправление будет выпущено.

Здесь та же проблема.

Можно подтвердить, что обходной путь @ command-tab все еще работает.

Это определенно все еще происходит с доморощенными pipenv и python ... немного удивлен, что нет теста, чтобы охватить это, видя, как долго эта проблема существует ...

Я также могу подтвердить, что эта проблема все еще возникает, несмотря на то, что проблема с GitHub закрыта.

Нужен ли сопровождающим для создания нового выпуска?

Та же проблема с Ubuntu 18 LTS, установленным в подсистеме Windows для Linux.

У меня работает обходной путь.

@techalchemy, похоже, эта проблема все еще существует. Не могли бы вы снова открыть его или дать понять, что хотите создать новый выпуск?

Благодарю.

Та же проблема с Ubuntu 18 LTS, установленным в подсистеме Windows для Linux.

тоже самое

@techalchemy, пожалуйста, взгляните еще раз

Такая же проблема здесь на macOs Mojave и python 3.7

Я тоже:

• Каталина
• Python 3.7.

Все работает нормально, как только я закомментирую эту строку в своем Pipfile:

[requires]

#python_version = "3.7.4"

Я тоже:

• Каталина
• Python 3.7.

Все работает нормально, как только я закомментирую эту строку в своем Pipfile:

[requires]

#python_version = "3.7.4"

аааа, это сработало для меня, спасибо!

@JarredStanford @edsu
Это сработало и для меня на WSL в VSCode (я не пробовал использовать внешнюю оболочку, поскольку она отлично работала для другого проекта).

@ command-tab
Добавление "--python = which python3 " также сработало. Я не пробовал добавлять "--three", и это кажется необязательным для моего варианта использования / версии.

Получив оба обходных пути, и я смог заставить его работать, я удалил их и попробовал в третий раз, чтобы убедиться, что среда по-прежнему вызывает проблему (рассказчик: это было).

@techalchemy
Думаю, это может быть не "полностью исправлено" в 3330? Это может быть второстепенная проблема, вызывающая те же симптомы. В моем случае я использую WSL и задаюсь вопросом, кажутся ли подозрительными «python3» и «python3.exe» на моем пути к WSL.

Считаете ли вы, что лучше всего открыть новую проблему, провести дополнительную диагностику или что-то еще?

Я использую wsl2 с arclinux (manjaro)
Кажется, pipenv вызывает python в окнах хоста env для установки
поэтому нам нужно определить, где найти питон:
pipenv --python=<PATH_TO_PYTHON>
или же
pipenv --python=which python3

работает на меня.

Могу подтвердить, что это происходит в WSL с Ubuntu 18.04 LTS. Похоже, что pipenv ищет интерпретатор python, а не использует тот, под которым он выполняется, и при этом проходит PATH в обратном порядке. У меня установлено несколько сред python, и всякий раз, когда я вручную удаляю одну из PATH, pipenv найдет другую и вместо этого пожалуется на нее.

Я вижу ту же проблему в WSL с Ubuntu 18.04 LTS. pipenv install --python $(which python3) работает, но когда я впоследствии выполняю pipenv shell , он не может найти зависимости, которые должен был загрузить.

Также меня затронуло использование WSL 1 и Ubuntu 18.04. Обходной путь --python $(which python) работает.

Причина последней части исключения, то есть этого бита:

  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)

... потому что есть ошибка в вызове для вывода ошибки при обработке первого исключения. Эта ошибка, похоже, уже была исправлена ​​в мастере еще в январе 2019 года - https://github.com/pypa/pipenv/commit/574fe7308d9ac81d64da954722f35c9eee0dd467#diff -a59595db75020aeb9f688d6a0b4818e6L162. Но поскольку последняя версия pipenv - 2018.11.26, я полагаю, что у большинства нет фиксированной версии.

Патчить можно вручную. Откройте /usr/local/lib/<your-python-version>/site-packages/pipenv/vendor/vistir/misc.py , перейдите к строке 162 и измените это:

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

... к этому:

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

Теперь вы получите более точный отчет об исключениях. В моем случае проблема связана с тем, что pipenv на основе WSL Linux обнаруживает установки Python на основе Windows и испытывает проблемы с их запуском, что отчасти очевидно:

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"]

Я считаю, что для пользователей WSL эту проблему можно решить, убедившись, что любые требования к вашей версии Python в Pipfile _ точно_ совпадают с установкой Python на базе Linux, например

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

Надеюсь это поможет.

Не уверен, насколько это помогает, но удаление Pipfile, запуск pipenv lock , а затем возвращение содержимого старого Pipfile и запуск pipenv install работает для меня навсегда.