Сталкивался ли с проблемами конфликтов зависимостей в Python

Что проверяют

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

Как отвечать

Объясните природу конфликта: два пакета требуют несовместимые диапазоны третьего. Современный pip с этим не мирится, он честно перебирает варианты и сообщает о тупике, вместо того чтобы молча поставить последнюю версию поверх.

Порядок действий:

• воспроизвести в чистом окружении (venv или контейнер), а не чинить свою рабочую машину;
• посмотреть дерево через pipdeptree и найти, кто задаёт узкое требование;
• решить по месту: ослабить собственный пин, обновить пакет с узким требованием, заменить библиотеку, в крайнем случае вынести конфликтующую часть в отдельный сервис.

Профилактика важнее лечения. Разделяйте прямые зависимости с диапазонами и полный слепок окружения: pip-tools, poetry или uv дают файл блокировки со всеми транзитивными версиями и хэшами, а CI ставит строго из него. В библиотеке пины должны быть широкими, в приложении жёсткими. Упомяните, что версия интерпретатора тоже часть контракта, а колёса собираются под конкретную платформу.

Где спотыкаются

Рассказывают, как решили конфликт через --force-reinstall и установку нужной версии поверх. Pip замолчал, несовместимость осталась, и она вылезет в рантайме как ImportError или пропавший аргумент функции. Это описание ошибки, а не решения.

Считают, что виртуальное окружение решает конфликт. Оно изолирует проекты друг от друга, но внутри одного окружения два пакета всё так же тянут разные версии третьего.

Пинят всё жёстко везде, включая собственные библиотеки. Библиотека, где на каждую зависимость стоит ==, не устанавливается рядом почти ни с чем и превращает любое обновление в ручную работу.