Как исправить ModuleNotFoundError в pip из-за путаницы между venv и pipx

Разбираем ошибку ModuleNotFoundError в pip из-за смешения окружений venv и pipx: как активировать venv, обновить pip и переустановить пакеты. Без ошибок.

Запуск приложения на Python и внезапное появление ModuleNotFoundError от pip — вещь раздражающая, особенно когда вы уверены, что окружение настроено корректно. Типичная картина — pip пытается импортировать свои внутренние модули и падает, будучи запущенным из неожиданного места. Это чаще указывает на несоответствие окружений, а не на поломанный пакет, который вы пытаетесь установить.

Как выглядит ошибка

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/__main__.py", line 22, in <module>
    from pip._internal.cli.main import main as _main
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/main.py", line 11, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/autocompletion.py", line 10, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/cli/main_parser.py", line 9, in <module>
    from pip._internal.build_env import get_runnable_pip
  File "/home/mel/.local/share/pipx/shared/lib/python3.12/site-packages/pip/_internal/build_env.py", line 23, in <module>
    from pip._internal.utils.temp_dir import TempDirectory, tempdir_kinds
ModuleNotFoundError: No module named 'pip._internal.utils.temp_dir'

Сведения об окружении на тот момент показывали Python 3.12.3 и pip 25.1.1 внутри виртуального окружения. Также предпринималась попытка установить пакеты вроде moviepy и сопутствующие через прямой вызов интерпретатора Python из venv, а отдельный вызов ensurepip сообщил, что pip уже установлен. Команда установки выглядела так:

xxx:~$ $HOME/.venvs/MyEnv/bin/python -m pip install moviepy SpeechRecognition pydub pysrt googletrans==4.0.0-rc1 gtts

В чём на самом деле проблема

Трассировка ясно показывает, что путь импорта pip указывает на каталог под управлением pipx: /home/mel/.local/share/pipx/shared/lib/python3.12/site-packages. Это означает, что процесс, пытавшийся использовать pip, выполнялся не в том виртуальном окружении. Параллельно наблюдалась непоследовательность в вызове интерпретатора (смешивались python и python3) и ненужный заход через ensurepip. Суть проблемы — не в moviepy, а в том, что pip импортируется из другого окружения, отличного от того, где живут ваши пакеты.

Как исправить

Как только управление взяло нужное окружение, решение стало очевидным. Сначала активируйте виртуальное окружение, чтобы и интерпретатор, и pip использовались именно из него. Затем удалите ранее установленный moviepy в этом окружении, обновите pip в нём же и установите moviepy заново. Конкретно сработала последовательность: активировать venv, удалить moviepy, обновить pip из активного окружения и установить moviepy снова.

Обновление pip из активного окружения:

python -m pip install --upgrade pip

Если вам удобнее явно указывать версию интерпретатора, то же обновление можно выполнить так:

python3 -m pip install -U pip

Когда в правильном окружении установлен актуальный pip, повторно выполните установку пакетов тем интерпретатором, который принадлежит окружению, например:

xxx:~$ $HOME/.venvs/MyEnv/bin/python -m pip install moviepy SpeechRecognition pydub pysrt googletrans==4.0.0-rc1 gtts

Ещё один практический совет: последовательно используйте python3 во всех командах, чтобы случайно не обратиться к другому исполняемому файлу интерпретатора.

Почему это важно

Смешивание инструментов и интерпретаторов из системного Python, pipx и venv обычно приводит к «призрачным» сбоям вроде отсутствующих внутренних модулей: pip импортируется из места, которое не предназначено для текущего запуска. Гарантируя, что каждый шаг — обновление, удаление, установка — выполняется в одном и том же виртуальном окружении, вы предотвращаете перекрёстное загрязнение путей и получаете надёжную диагностику. Это помогает не гоняться за ложной причиной: здесь исключение касалось внутренних модулей pip, а не moviepy.

Выводы

Всегда активируйте виртуальное окружение перед установкой или обновлением чего-либо — так вы задействуете правильный путь site-packages. Используйте единообразный префикс для интерпретатора, например python3 -m pip, чтобы контролировать, где именно работает pip. Если в трассировке видно, что pip берётся из пути pipx, а вы собирались использовать venv, остановитесь и сначала приведите контекст в порядок. Если установка пакета пошла не так, чистое удаление, обновление pip в активном окружении и повторная установка — часто самый короткий путь к успешному результату.