Python pip: установка пакетов, управление версиями и работа с PyPI

Что такое pip на самом деле

pip — это инструмент, который ставит Python-библиотеки, которые ты сам не писал. Когда ты запускаешь pip install requests, он ищет requests на PyPI (Python Package Index), скачивает подходящую версию под твою платформу и кладёт в каталог site-packages твоего Python-а. После этого import requests работает.

Любая установка Python 3 с python.org, Homebrew или пакетного менеджера Linux уже идёт с pip. Перед тем как что-то ставить, проверь:

python -m pip --version

Должен увидеть номер версии и путь к модулю pip. Если команда падает, самый надёжный способ починить:

python -m ensurepip --upgrade

Это бутстрапит pip в твою установку Python копией, которую поставляет сам интерпретатор.

python -m pip vs pip

Ты увидишь обе формы. Они делают почти одно и то же, но с одним важным отличием: python -m pip использует python из твоего PATH — тот же, что твои скрипты. Голый pip использует тот pip, который оказался первым, а это не всегда то же самое.

Когда установлено несколько Python-ов (на macOS легко так оказаться), голый pip — это тот самый путь к запутанной ситуации «я установил библиотеку, а мой код всё ещё пишет ModuleNotFoundError».

Правило большого пальца: python -m pip ..., когда хочется уверенности, какому интерпретатору достанется пакет. Голый pip — для быстрой работы, когда уверен.

Установка пакета

Базовая команда:

python -m pip install requests

Она тянет requests с PyPI вместе со всем, от чего он зависит, и ставит их. Через минуту можно пользоваться:

Установка нескольких пакетов разом:

python -m pip install requests pandas rich

Фиксация конкретной версии:

python -m pip install "django==5.0.2"
python -m pip install "requests>=2.30,<3"

Кавычки важны в некоторых оболочках — они не дают == и < интерпретироваться как операторы шелла.

Обновление и удаление

python -m pip install --upgrade requests
python -m pip uninstall requests

--upgrade тянет самую свежую версию, удовлетворяющую указанному ограничению. uninstall удаляет пакет, но не его зависимости — они остаются, пока не удалишь явно.

Чтобы держать сам pip актуальным:

python -m pip install --upgrade pip

Стоит запускать раз в несколько месяцев. Новые версии pip лучше ловят проблемы установки и резолвят зависимости.

Что установлено

python -m pip list
python -m pip show requests

list показывает все пакеты, установленные в текущем Python. show requests печатает версию, расположение, зависимости и лицензию конкретного пакета — пригодится, когда интересно «какую версию я на самом деле использую?».

requirements.txt: фиксируем зависимости

Когда в проекте больше пары библиотек, запиши их список. pip freeze сделает это:

python -m pip freeze > requirements.txt

Получится файл со строкой-зависимостью на строку:

django==5.0.2
requests==2.31.0
rich==13.7.1

Любой, кто склонирует репозиторий, воспроизведёт установку командой:

python -m pip install -r requirements.txt

pip freeze захватывает всё установленное, включая транзитивные зависимости. Это удобно для точной воспроизводимости, но шумно, если нужны только верхнеуровневые библиотеки, которые твой код реально импортирует. Многие проекты держат requirements.txt руками — только прямые зависимости, а транзитивные пусть разрешает pip.

В современных проектах pyproject.toml (в паре с инструментами вроде pip-tools, uv, poetry или hatch) вытесняет requirements.txt. Идея та же — «запиши зависимости, запусти команду, поставь их», — но формат файла более структурированный.

Всегда ставь в виртуальное окружение

У любого реального Python-проекта должно быть своё виртуальное окружение. Это папка внутри проекта со своим python и своими пакетами — так что pip install в одном проекте не влияет на любой другой.

Две строки настройки:

python -m venv .venv
source .venv/bin/activate    # macOS / Linux
# or .venv\Scripts\activate on Windows

После активации python -m pip install requests ставит в venv. Системный Python остаётся чистым. Подробнее — на странице про виртуальные окружения.

Если, запустив pip install, ты видишь предупреждение об установке в системный Python (или сообщение о том, что нужен --break-system-packages) — остановись. Это сигнал создать venv.

Когда pip не может поставить пакет

Несколько типичных отказов и что они означают:

• Could not find a version that satisfies the requirement … — обычно опечатка в имени пакета или пакет требует Python свежее, чем у тебя.
• error: Microsoft Visual C++ 14.0 or greater is required (Windows) — у пакета есть нативное расширение, и ему нужен C++ билд-тулчейн. Либо ставь Microsoft Build Tools, либо ищи готовое wheel (большинство популярных пакетов их предоставляют).
• Permission denied — ты пытаешься поставить в системный Python без root. Правильный ремонт не sudo pip install, а виртуальное окружение.
• ModuleNotFoundError после установки — почти всегда случай, когда pip install положил пакет в другой Python, не в тот, что запускает скрипт. Проверь which python и which pip (macOS/Linux) или where python / where pip (Windows). Или надёжнее — python -m pip install ....

Современные альтернативы pip

Несколько инструментов, о которых ты будешь слышать, — все совместимы с pip и решают конкретные боли:

• uv — существенно более быстрый установщик и резолвер. Замена для большинства pip-команд.
• pipx — ставит CLI-инструменты (вроде black, ruff, httpie) в изолированные venv-ы, так что они доступны глобально, не конфликтуя с зависимостями проектов.
• poetry и hatch — менеджеры проектов, объединяющие виртуальные окружения, резолвинг зависимостей и сборку в один инструмент.

В первый день они не нужны. Сначала освой pip; тянись к остальным, когда их боль станет твоей.

Дальше: виртуальные окружения

Пакеты и виртуальные окружения идут парой. Ты уже видел почему; следующая страница подробно показывает venv — создание, активацию, деактивацию и маленькие соглашения, которые держат Python-проекты в порядке.