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. Я полагаю, это не имеет значения для разрешения заказа.