- Исполняемый файл, на который ссылается пустая команда, такая как
pip, в файловой системе зависит от $ PATH. Найдите в which pip правильный вариант (type pip, если кто-то действительно был злым и сделал для него псевдоним оболочки). Загляните в which -a pip, чтобы увидеть, что окружают другие, которые могут быть затенены первым. Обратите внимание, что некоторые оболочки кэшируют сопоставление команд и файлов, а иногда испортят их недействительность кэша (попробуйте hash -r, если вы видите странное поведение и думаете, что ваша оболочка имеет испорченный кэш). - Такая команда, как
./pip или .venv/bin/pip будет не искать в $ PATH. Это потому, что в нем есть косая черта. - ОК, так что вы нашли файл
pip, это исполняемый скрипт. Первая строка этого файла, называемая shebang , сообщает вам, какой интерпретатор связан с этим сценарием pip. Посмотри в head -1 .venv/bin/pip. Если pip был установлен в venv, то это всегда будет соответствовать Python для venv, если вы не редактировали его вручную, потому что сам установщик записывает этот shebang (забавный факт: даже если вы вставите другой прямо в исходный код,установщик переписал его!). pip install поместит файлы туда, где говорит sysconfig соответствующего интерпретатора. Точка 1 говорит вам точно, что означает «пункт», а точка 2 показывает вам, что именно означает «связанный интерпретатор». Расположение sysconfig зависит от платформы. Выясните, где, запустив path/to/python -m sysconfig | grep "Paths:" --after 10, найдите путь "purelib".
Нет ничего волшебного в том, чтобы "активировать" venv, он просто устанавливает переменные env, такие как $ PATH. Если вы понимаете, как работает 1-3, вы понимаете, как работает активация venv.
Так что теперь вы должны быть в состоянии аргументировать ответ, не угадывая: использование пути типа .venv/bin/pip вместо активации venv (который меняет $ PATH, который меняет то, что означает pip, в результате получается тот же .venv/bin/pip) без разницы.
Приложение: Почему у людей так много проблем с установкой пипсов?
Плохая гигиена. Я думаю, что они испортили свои системы, так или иначе связавшись с sys.path (добавив его в сценарии запуска, сайт пользователя, sitecustomize.py, установив PYTHONPATH env var в .bashrc, установив какой-то дерьмовый пакет, который его мутировал, следуя какому-то дерьмовому руководству, у которого было sudo pip install ... возможности безграничны!)
Посмотрите на pip «скрипт», это просто консольная запись-точка написана setuptools. Этот скрипт создается из шаблона во время установки. На самом деле вы не найдете этот файл в источнике pip, потому что его там нет .
#!/path/to/.venv/bin/python3
# -*- coding: utf-8 -*-
import re
import sys
from pip._internal.main import main # <--- look at this import statement!
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(main())
Первое, что делает исполняемый скрипт, это пытается импортировать его частные API из pip модуля , и где разрешение этого from pip модуля будет решено, зависит от sys.path. Первый матч выигрывает. Когда pip появляется случайно, вы должны задаться вопросом: «Этот оператор импорта все еще находит тот же файл pip/__init__.py, который был записан программой установки при создании сценария?»
Если это не так, илиШебанг выглядит неправильно, просто удалите его и переустановите pip.