Ошибка Pip после перехода с bash на zsh
Как упоминалось в другом вопросе , при установке GNU sedс помощью Homebrew с --with-default-namesон устанавливается как /usr/local/bin/sed.
Без --with-default-namesон будет установлен как /usr/local/bin/gsed.
Если установлен как sed, то это зависит от вашего $PATH, какой двоичный файл sedбудет выбран при выполнении sed. Если ваш $PATHтакой, как вы описали, то GNU sedдолжен иметь приоритет над собственной macOS sed.
Обратите внимание, что оболочка могла уже кэшировать расположение команды sed, если вы ранее использовали эту команду в командной строке в том же сеансе оболочки. Затем вы можете использовать rehashв zsh, чтобы очистить этот кеш или открыть новый терминал.
Когда система предоставляет нативную sedреализацию, отличную от GNU sed, часто лучше установить GNU sedкак gsed, чтобы не нарушать существующие сценарии, полагаясь на поведение, характерное для нативной sed. Вот почему поведение Homebrew по умолчанию в macOS заключается в установке GNU sedкак gsed. Это также способ по умолчанию именовать GNUsed(и инструменты GNU вообще )в других системах BSD.
Эта странность может быть вызвана некоторыми различиями в версиях PATH и python/pip.
Предлагаю проверить вывод этих команд, как в bash, так и в zsh:
pip --version
python -m pip --version
pip2 --version
python2 -m pip --version
pip3 --version
python3 -m pip --version
Как предложил @Kusalananda , вам также необходимо проверить файлы инициализации, такие как .bashrc. Это зависит... иногда легче сравнить результаты setв среде zsh/bash. Этот diff, вероятно, огромен (1k строк или больше ), так что это все равно, что искать иголку в стоге сена. Отсутствуют или изменены переменные (, такие как PATH )и PYTHONNOUSERSITE, PYTHONPATH и все, что начинается с PIP или содержит PIP (или PY? )функции оболочки (as pip (){... } )могут учитываться.
Я видел это сообщение об ошибке, и это была проблема, связанная с моим $PATH.
Вот несколько шагов по устранению неполадок.
Вы можете просмотреть свой путь с помощью echo $PATH.
which pipи which pythonдолжны возвращать одно и то же местоположение. Эти команды ищут каталоги в вашем $PATH, чтобы найти первое место, содержащее исполняемый файл.
Если вы используете pyenv, which pipи which pythonвернут один и тот же каталог «shims», но это не обязательно означает, что исполняемые файлы запускаются из одного и того же каталога. В этом случае используйте pyenv which pipи pyenv which python.
В моем случае у моего $PATH был каталог ~/.local/bin/, который добавлялся в начале, когда я запускал внутри tmux. ~/.local/bin/имел исполняемый файл pip, но не исполняемый файл python. Поэтому я пытался использовать версию Python pyenv, но версию pip ~/.local/bin/pip.
изменить, чтобы уточнить:
Если which pipи which pythonпоказывают разные пути, или в случае pyenv, если pyenv which pipи pyenv which pythonпоказывают разные пути, проблема может заключаться в этом.
Решение будет зависеть от вашей среды, поэтому трудно дать одно -решение, -подходящее -для всех ответов.
Возможно, ваш $PATHимеет~/.local/binдо /usr/bin, а ~/.local/binимеет исполняемый файл pip, но не python. Таким образом, ваш компьютер находит pipв ~/.local/bin, но находит pythonв /usr/bin. В этом случае вы можете удалить pipв ~/.local/bin, если он вам не нужен. Или вы можете обновить его, чтобы он был символической ссылкой на пункт в /usr/bin(, предполагая, что у вас есть другой pipисполняемый файл ). Или вы можете добавить символическую ссылку ~/.local/bin/pythonна /usr/bin/python. Или вы можете обновить свой $PATH, чтобы он искал/usr/binдо поиска ~/.local/bin.
Решение зависит от вашей среды, способа установки Python, версии, которую вы хотите использовать, и т. д.