Pip, pipx и poetry: что ставить новичку и в чём разница

Вы поставили пакет через pip install, потом второй проект потребовал другую версию той же библиотеки — и первый проект перестал запускаться. Или вы установили black глобально, а он потянул за собой десяток зависимостей, которые конфликтуют с рабочим проектом. Это две разные проблемы, и решают их два разных инструмента. Разберём, что делает pip, pipx и poetry, чем они не пересекаются и с чего начать в 2024 году.

Что это за три инструмента и зачем их три

Все три работают с пакетами из PyPI¹, но отвечают за разные задачи. Путаница начинается, когда новичок пытается решить одну задачу инструментом для другой.

• pip — базовый установщик пакетов. Ставит библиотеку в текущее окружение Python. Поставляется вместе с Python начиная с версии 3.4, отдельно устанавливать не нужно.
• pipx — обёртка над pip и виртуальными окружениями. Ставит приложения командной строки (написанные на Python) в изолированные окружения, но делает их доступными глобально из терминала.
• poetry — менеджер зависимостей и сборки проекта. Управляет всеми библиотеками одного проекта, фиксирует их точные версии в lock-файле и умеет собирать пакет для публикации.

Ключевая мысль: pip ставит библиотеки в проект, pipx ставит утилиты в систему, poetry держит зависимости всего проекта под контролем.

Если вы ставите библиотеку, чтобы её импортировать в коде — это pip или poetry. Если вы ставите программу, которую будете запускать из терминала — это pipx. Спутать эти две ситуации и есть главная ошибка новичка.

pip: чего не хватает из коробки

pip умеет одно: установить пакет в тот интерпретатор Python, который сейчас активен. Проблема в слове «активен». Без виртуального окружения pip ставит всё в системный Python, и проекты начинают тянуть зависимости друг у друга.

Стандартный безопасный сценарий с чистым pip выглядит так:

# Python 3.12, создаём виртуальное окружение в папке проекта
python -m venv .venv

# активируем (Linux/macOS)
source .venv/bin/activate

# активируем (Windows PowerShell)
# .venv\Scripts\Activate.ps1

# теперь pip ставит пакеты внутрь .venv, а не в систему
pip install requests

# зафиксировать версии для коллег
pip freeze > requirements.txt

Это работает, но pip freeze записывает разом и то, что вы поставили сами, и то, что подтянулось как зависимость зависимости. Через полгода вы не помните, какая строка в файле важна, а какая случайна. Именно эту слабость закрывает poetry.

pipx: для утилит, а не для библиотек

Есть инструменты, которые вы запускаете из терминала в любом проекте: форматтеры (black), линтеры (ruff), сборщики (httpie). Ставить их в каждый проект — расточительно, ставить глобально через pip — опасно: их зависимости замусоривают системный Python.

pipx для каждого такого приложения создаёт отдельное виртуальное окружение, но кладёт исполняемую команду в PATH. Вы получаете глобальную команду без глобального мусора.

# установка pipx (один раз)
python -m pip install --user pipx
python -m pipx ensurepath

# перезапустите терминал, затем ставьте утилиты
pipx install black
pipx install ruff

# посмотреть, что установлено
pipx list

После этого black . работает из любой папки, а зависимости black изолированы и не конфликтуют ни с одним вашим проектом.

poetry: один проект — один источник правды

poetry заменяет связку venv + pip + requirements.txt единым файлом pyproject.toml и lock-файлом poetry.lock. В pyproject.toml вы пишете только то, что нужно вам напрямую. poetry сам разрешает зависимости, а в lock-файл записывает точные версии всего дерева — чтобы у вас и у коллеги установился идентичный набор.

# установка poetry рекомендуемым способом — через pipx
pipx install poetry

# создать новый проект
poetry new myproject
cd myproject

# добавить зависимость (правит pyproject.toml и lock)
poetry add requests

# добавить инструмент только для разработки
poetry add --group dev pytest

# установить всё окружение из lock-файла
poetry install

# запустить что-то внутри окружения проекта
poetry run pytest

Начиная с poetry 1.2 группы зависимостей задаются через --group; в более старых версиях синтаксис был другим (--dev). Если копируете команды из старых статей — сверьтесь с версией poetry --version.

Сравнение: что для чего

Когда что выбирать

Три инструмента не конкурируют — они складываются в одну связку. Практичный порядок такой:

1. Учитесь и пишете первые скрипты. Хватит pip плюс venv. Не усложняйте: сначала научитесь понимать, что такое виртуальное окружение и почему без него всё ломается.
2. Нужны глобальные утилиты (форматтер, линтер, poetry). Ставьте их через pipx — так системный Python останется чистым.
3. Появился настоящий проект, который вы ведёте не один или который будете деплоить. Переходите на poetry: pyproject.toml и lock-файл дают воспроизводимость, которой не даёт requirements.txt.

Итоговая рабочая схема для новичка, который дошёл до реальных проектов: poetry для зависимостей проектов, pipx для установки самого poetry и других утилит, pip остаётся под капотом.

Что ломается чаще всего

• Смешение poetry и pip в одном проекте. Поставили пакет через pip install внутри poetry-окружения — и он не попал в pyproject.toml. У коллеги проект не запустится. Внутри poetry-проекта ставьте только через poetry add.
• pipx не в PATH. После установки команды вроде black не находятся. Причина — не выполнен pipx ensurepath или терминал не перезапущен.
• Установка библиотеки через pipx. pipx не для импортируемых библиотек. pipx install requests технически пройдёт, но импортировать requests в проекте вы не сможете — она лежит в изолированном окружении утилиты.
• Забыли про venv с чистым pip. pip install без активированного окружения ставит в системный Python и на Linux/macOS часто требует прав или падает с ошибкой externally-managed-environment — это защита от порчи системного интерпретатора.

Что делать дальше

Начните с малого: поставьте pipx, через него — poetry, заведите один тестовый проект командой poetry new и добавьте пару зависимостей через poetry add. Посмотрите, что появилось в pyproject.toml и poetry.lock — это и есть та самая воспроизводимость. Дальше стоит разобраться с версионированием зависимостей (кареты ^ и тильды ~ в pyproject.toml) и с тем, как poetry подхватывает уже существующее виртуальное окружение — это отдельная тема, здесь мы её не разворачивали.