Virtualenv использует неправильный питон, хотя он первый в $PATH
У меня возникла проблема, когда python не находил модули, установленные пиком, в то время как в virtualenv.
Я сузил его и обнаружил, что когда я вызываю python, когда мой virtualenv активирован, он по-прежнему достигает /usr/bin/python вместо /home/liam/dev/.virtualenvs/noots/bin/python.
Когда я использую which python в virtualenv, я получаю:
/home/liam/dev/.virtualenvs/noots/bin/python
Когда я просматриваю свою переменную $PATH в virtualenv, я получаю:
bash: /home/liam/dev/.virtualenvs/noots/bin:/home/liam/bin:/home/liam/.local/bin:/home/liam/bin:/home/liam/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory
и все же, когда я действительно запускаю python, он переходит в /usr/bin/python
Чтобы сделать вещи более запутанными для меня, если я запустил python3.5, он захватывает python3.5 из правильного каталога (т.е. /home/liam/dev/.virtualenvs/noots/bin/python3.5)
Я вообще не коснулся /home/liam/dev/.virtualenvs/noots/bin/. python и python3.5 все еще связаны с python3 в этом каталоге. Переход на /home/liam/dev/.virtualenvs/noots/bin/ и запуск ./python, ./python3 или ./python3.5 работают нормально.
Я использую virtualenvwrapper, если это имеет значение, однако проблема, похоже, произошла недавно, долго после установки virtualenv и virtualenvwrapper
Ответы
Ответ 1
Если вы не получите программу, которую which говорит, что вы должны ее получить, вам нужно посмотреть вверх по цепочке, чем исполнитель платформы. Обычно оболочка имеет способ для псевдонимов, а в большинстве оболочек unixy вы можете просто ввести alias, чтобы увидеть, какие команды были переназначены. Тогда это просто вопрос перехода к файлам конфигурации для вашей оболочки и удалению псевдонима.
Иногда люди alias python пытаются отсортировать, какой питон они должны использовать. Но обычно есть и другие, лучшие способы. Например, на моей машине linux python3 находится в пути, но является символической ссылкой на реальный питон, который я использую.
[email protected] ~ $ which python3
/usr/bin/python3
[email protected] ~ $ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Feb 17 2016 /usr/bin/python3 -> python3.4
[email protected] ~ $
Это хорошо, потому что программы без оболочки, на которых запущен python, получают то же самое, что и я, и виртуальные среды работают естественным образом.
Ответ 2
Моя проблема заключалась в том, что я недавно переместил свой проект с virtualenv в другое место, потому что у этого сценария activate был неверный путь VIRTUAL_ENV.
$ cat path_to_your_env/bin/activate
... # some declarations
VIRTUAL_ENV="/path_to_your_env/bin/python" # <-- THIS LINE
export VIRTUAL_ENV
... # some declarations
Чтобы это исправить, просто обновите VIRTUAL_ENV в скрипте activate.
Также вам может понадобиться исправить первую строку вашего bin/pip для ссылки на реальный путь Python.
Ответ 3
Как tdelaney, предложенный в комментариях, я запустил alias и обнаружил, что ранее я имел псевдоним python до /usr/bin/python3.5 в моем .bashrc.
Я удалил этот псевдоним из моих .bashrc, побежал unalias python и source ~/.bashrc, и проблема была решена.
Ответ 4
На Cygwin у меня все еще есть проблема даже после того, как я создал символическую ссылку, чтобы указать /usr/bin/python на F:\Python27\python.exe. Здесь, после source env/Scripts/activate, which python по-прежнему /usr/bin/python.
Спустя долгое время я разобрался с решением. Вместо использования virtualenv env, вы должны использовать virtualenv -p F:\Python27\python.exe env даже если вы создали символическую ссылку.
Ответ 5
У меня сейчас такая же проблема. Virtualenv был создан в Windows, сейчас я пытаюсь запустить его из WSL.
В virtualenv я переименовал python.exe в python3.exe (так как у меня есть только команда python3 в WSL). В $ PATH моя папка virtualenv - первая, псевдонима для python нет. Я получаю which python3
/usr/bin/python3. В /usr/bin/python3 есть символическая ссылка 'python3 → python3.6. Я полагаю, это не имеет значения для разрешения заказа.
