У меня возникла проблема, когда python не находил модули, установленные pip, в то время как в 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

27
liamhawkins 7 Янв 2017 в 20:25

4 ответа

Лучший ответ

Если вы не получаете программу, которую which говорит, что вы должны ее получить, вам нужно смотреть выше по цепочке, чем исполнитель платформы. Оболочки обычно имеют способ псевдонимов команд, и в большинстве оболочек Unixy вы можете просто ввести alias, чтобы увидеть, какие команды были переназначены. Тогда нужно просто перейти к файлам конфигурации вашей оболочки и удалить псевдоним.

Иногда люди псевдоним python, чтобы попытаться выяснить, какой питон они должны использовать. Но обычно есть и другие, лучшие способы. Например, на моем Linux-компьютере python3 находится в пути, но является символической ссылкой на реальный питон, который я использую.

td@mintyfresh ~ $ which python3
/usr/bin/python3
td@mintyfresh ~ $ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Feb 17  2016 /usr/bin/python3 -> python3.4
td@mintyfresh ~ $ 

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

4
tdelaney 7 Янв 2017 в 17:53

Моя проблема заключалась в том, что я недавно переместил свой проект с помощью 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.

13
vishes_shell 9 Июл 2019 в 23:28

В 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, даже если вы создали символическую ссылку.

1
Gaoping 8 Янв 2019 в 23:08

Как tdelaney предложили в комментариях, я запустил alias и обнаружил, что ранее использовал псевдоним python на /usr/bin/python3.5 в моем .bashrc.

Я удалил этот псевдоним из своего .bashrc, запустил unalias python и source ~/.bashrc, и проблема была решена.

6
liamhawkins 7 Янв 2017 в 17:47