> Какие пакетные менеджеры используются в Python (Python)

Короткий ответ

Основные пакетные менеджеры в Python - pip, pipenv, poetry и uv. pip - стандартный и минимальный, работает с requirements.txt. pipenv и poetry добавляют управление виртуальным окружением и lock-файлы для воспроизводимости. uv - современный высокопроизводительный менеджер, написанный на Rust, совместимый с pip и pyproject.toml. Для управления самим Python часто используют pyenv или conda.

Подробное объяснение

pip - базовый инструмент, встроенный в Python. Устанавливает пакеты из PyPI, но не решает конфликты зависимостей и не изолирует окружения. Требует ручного управления через requirements.txt или requirements-dev.txt.

pipenv появился как попытка объединить pip и virtualenv. Использует Pipfile и Pipfile.lock. Автоматически создаёт виртуальное окружение и разделяет зависимости на production и dev. Однако проект сейчас в режиме поддержки, развитие замедлилось.

poetry - более современный подход. Центральный файл - pyproject.toml (стандарт PEP 621). Генерирует poetry.lock для точной воспроизводимости. Умеет собирать и публиковать пакеты, управляет виртуальными окружениями. Хорошо интегрируется с CI/CD.

uv - новый инструмент от создателей ruff. Очень быстрый (в десятки раз быстрее pip), поддерживает pyproject.toml, requirements.txt, lock-файлы, кэширование, управление версиями Python. Может заменять pip, pipenv, poetry и частично pyenv.

conda - менеджер пакетов и окружений, не ограничен Python. Полезен для научных вычислений, когда нужны бинарные зависимости (CUDA, BLAS). Но тяжелее и медленнее.

Выбор зависит от проекта: для простых скриптов - pip, для библиотек и командной работы - poetry или uv, для data science - conda.

На практике

Для production-проектов важно, чтобы lock-файл был в репозитории - это гарантирует одинаковые версии на всех окружениях. pip freeze не даёт такой гарантии, так как не учитывает транзитивные зависимости корректно.

При работе в команде стоит зафиксировать единый менеджер в документации и CI. Если проект уже использует requirements.txt, переход на poetry или uv оправдан, когда появляются проблемы с воспроизводимостью или скоростью установки.

Для библиотек, публикуемых в PyPI, pyproject.toml обязателен (PEP 621). poetry и uv генерируют его автоматически, pip - нет.

Пример кода

Установка с pip:

BASH
pip install requests
pip freeze > requirements.txt

Установка с poetry:

BASH
poetry add requests
poetry lock
poetry install

Установка с uv:

BASH
uv add requests
uv lock
uv sync

Пример pyproject.toml для poetry:

[tool.poetry]
name = "my-project"
version = "0.1.0"
description = ""
authors = ["Name <email@example.com>"]

[tool.poetry.dependencies]
python = "^3.11"
requests = "^2.31.0"

[tool.poetry.group.dev.dependencies]
pytest = "^7.4.0"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

Как отвечать на собеседовании

Начните с pip как базового, затем упомяните poetry и uv как современные альтернативы. Объясните разницу между requirements.txt и lock-файлами. Покажите понимание, зачем нужен pyproject.toml. Если спросят про выбор - аргументируйте: для новых проектов предпочтителен uv или poetry, для легаси - pip. Упомяните pipenv как исторический этап, но не рекомендуйте его для новых проектов.

Что проверяет интервьюер

• Понимание разницы между менеджерами и их сильных сторон
• Знание lock-файлов и воспроизводимости окружений
• Осведомлённость о современных инструментах (uv)
• Умение обосновать выбор под конкретный сценарий
• Понимание pyproject.toml и PEP 621

Типичные ошибки

• Рекомендация pipenv для новых проектов без оговорок
• Утверждение, что pip freeze - достаточный способ фиксации зависимостей
• Путаница между pyproject.toml и setup.py
• Игнорирование uv как нового стандарта
• Непонимание, зачем нужен lock-файл, если есть requirements.txt
• Совет использовать conda для обычных веб-проектов - это избыточно