TLDR
- понять приоритет ПУТИ
- понять, где обычно устанавливается ПУТЬ
- убедитесь, что ваша версия python использует соответствующую команду pip shell
Хотя это специально ориентировано на virtualenvwrapper, это может помочь вам понять, почему установленная вами команда оболочки по какой-то причине не работает.
Если вы когда-либо использовали virtualenvwrapper, вы знаете, как полезно смешивать и сопоставлять версии python и иметь отдельные силосы зависимостей для каждого проекта, чтобы вы не использовали один и тот же pip для каждого проекта. В некоторых редких случаях virtualenvwrapper может вызвать проблемы, если у вас установлено несколько версий python.
В моем случае mkvirtualenv потерпит неудачу при указании другого интерпретатора python, чем то, что было по умолчанию. Я хотел использовать python 3.7, и он выбирал пакеты pip из python 2.7. Команда, которую я использовал, была чем-то вроде mkvirtualenv-p python3 my-env .
После анализа моей установки возникла пара проблем. У меня было несколько версий python из разных источников, некоторые из macports, некоторые из homebrew, а также встроенный python, который был предустановлен вместе с Mac OS.
Чтобы решить, что происходит, я должен был понять проблему. Конечная проблема заключалась в том, что python 3.7 пытался использовать pip для python 2.7. Это было очевидно из исключений python, где было очевидно, что используемый интерпретатор был python 3.7, но трассировка стека показывала пути, ссылающиеся на python 2.7.
Что мне нужно было сделать, так это убедиться, что правильный канал был установлен для python 3.7. Homebrew, по крайней мере на моей машине, взял последнюю запись, в которой путь macports bin имел приоритет (появился первым в ПУТИ) над путем homebrew bin. Это важно понять, потому что ПУТЬ работает очень просто. Какой бы путь ни был определен первым, он будет использован первым для поиска команды оболочки, которую вы хотите запустить. Поэтому, если вы запустите $ python и /opt/local/bin сначала определитесь в PATH, то он разрешится в /opt/local/bin/python .
Я подумал, что мог бы убрать питон macports с картинки, чтобы посмотреть, не он ли вызывает проблемы. Для этого я использовал port select python none . Насколько я могу судить, это привело к удалению символической ссылки из пути к корзине macports. По какой-то причине это не делало ничего странного. Так что мне нужно было исследовать больше.
Я не забыл следить за тем, что находится в ПУТИ, поскольку это в основном контролирует, какая команда оболочки будет выбрана первой. Когда я это сделал echo $PATH Я заметил, что там все еще была ссылка на macports python. Этого определенно не должно было случиться. Я уже запустил port select python none . Среда $PATH устанавливается в нескольких местах. В общем вот пара мест для поиска с самым высоким приоритетом перечисленным первым:
- /etc/профиль
- /etc/bashrc
- ~/.bash_profile
- ~/.профиль
- ~/.bashrc
Виновник был в ~/.профиле. Там была запись, которая предваряла $PATH с macports python version export PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH . После того, как я прокомментировал это, моя оболочка закончила тем, что взяла версию homebrew, как я и намеревался. Я проверил это, запустив which python и увидев, что он берет данные из homebrew bin path usr/local/bin/|, а не из macports bin path opt | local/bin//. Однако была проблема: команда homebrew python на самом деле была python 2.7, а не 3.7, которую я хотел использовать.
Я узнал, что homebrew устанавливает python 3.7 как python3. Я мог бы просто сделать символическую ссылку из python3 python, но тогда мне нужно было бы следить за тем, что я действительно сделал. В Macports есть команда port select , где я мог бы поменять местами разные версии одной и той же программы, но у homebrew этого нет. Самая близкая вещь-это brew link и unlink, но она работает не так, как в macports. Все, что он делает, это удаляет программу из пути homebrew bin. Так что это мне не очень помогло.
Когда я вернулся назад, то вспомнил, что по какой-то причине python 3.7 пытался использовать pip, установленный для python 2.7. Когда я запустил brew link-vd , чтобы показать мне подробный вывод, там не было никаких ссылок на pip, которые я нашел очень подозрительными. После некоторых поисков в Google я обнаружил, что кто-то рекомендовал сделать brew переустановить python. Это оказалось решающей командой, которая установила pip для python 3.7. В итоге он использовал установку pip, но brew называет двоичный файл pip3 вместо pip. В homebrew pip предназначен для python 2.7.
Следующая часть очень важна, потому что она не так проста, как указание версии интерпретатора python, которую вы хотели бы использовать в mkvirtualenv-p python3 . Похоже, что virtualenvwrapper по умолчанию использует версию python и версию pip того, что установлено в данный момент. Как я уже упоминал ранее, установлен python 2.7 от homebrew. Таким образом, чтобы обойти эту проблему, virtualenvwrapper имеет переменную окружения, которую вы можете установить в интерпретатор python, который вы хотели бы использовать для самого virtualenvwrapper. Он называется VIRTUALENVWRAPPER_PYTHON. Вы устанавливаете его на абсолютный путь интерпретатора python, который хотите использовать. В моем случае я сделал export VIRTUALENVWRAPPER_PYTHON=`which python3` . Теперь , когда я запускаю mkvirtualenv-p python3 , он не выдает никаких исключений python, пытаясь использовать pip для python 2.7.