enamored_poc 23 ноя в 09:27

Poetry vs Pip: Почему пора перестать использовать requirements.txt

12 мин

13K

Python *

Обзор

+31

Комментарии 35

ic10 23 ноя в 09:45

# в requirements.in основные зависимости
# в requirements.txt уже полные зависимости как после freeze
uv pip compile requirements.in -o requirements.txt
uv pip sync requirements.txt

# можно просто использовать pip-tools
# но uv делает то же самое гораздо быстрее

Да и Poetry, вроде, сейчас уже считается не слишком модным, все хвалят uv.

ra4hgn 23 ноя в 11:31

да, в рамках продвижения rust в мир python, это актуально :)

Elendiar1 24 ноя в 07:00

Ага, еще год назад перешёл с поетри на uv. Еа тот момент разница в скорости резольва зависимостей была коллосальной

Eveneven1 23 ноя в 09:49

Выкиньте pip/poetry и заюзайте uv.

Там есть и установка питона, и lock файлы и куча других преимуществ.

A-V-tor 23 ноя в 11:03

например, какие у uv преимущества перед poetry кроме скорости?

Eveneven1 23 ноя в 13:08

Кроме скорости (которая очень важна в CI) - одной командой можно развернуть себе окружение, поставить нужную версию питона и т.д.

Ну и на него сейчас много проектов переводят (и opensourse и коммерческих).

A-V-tor 24 ноя в 04:10

А в poetry, что 10 команд чтобы развернуть себе окружение?
К тому же в поэзии есть команда для активации вирт. окружения в отличии от uv

Ну и на него сейчас много проектов переводят (и opensourse и коммерческих). - Все прыгают с обрыва и я прыгну

Eveneven1 24 ноя в 04:39

На Вашу аргументацию могу только пожелать удачи в сидении и дальше на питоне 3.11 и poetry 1.x.x в конце 2025 года)))

A-V-tor 24 ноя в 04:55

Так я искренне хочу уловить плюсы перехода на uv
Момент по скорости ясен, я спросил есть ли что-то еще, по факту ваших ответов судя по всему нет (без негатива).
Если есть у кого что добавить, я бы почитал, так как действительно интересно.

iroln 24 ноя в 09:34

В uv резолвер зависимостей работает не совсем так как в Poetry, можно более гибко настроить, чтобы не ругался на ограничение сверху, например. Некоторые авторы библиотек любят зарезать версию питона сверху, типа <3.11, и это ломает резолвер зависимостей Poetry, если в других зависимостях версия питона сверху не ограничена. Ограничивать версию питона сверху - это вообще плохая практика, не надо так делать без серьёзной необходимости, вызванной совместимостью C-API и т. д. Но даже в scipy, numpy, которые сильно зависят от C-API, от этого отказались после долгих дискуссий. Контекст: https://iscinumpy.dev/post/bound-version-constraints/

В Poetry удобнее чем в uv обновлять и бампить версии зависимостей. В остальном uv лучше.

Скорость работы uv просто на порядки выше чем Poetry, особенно на огромных графах зависимостей. Он работает мгновенно там где Poetry может тупить минутами.

thethee 24 ноя в 22:08

А что, .venv/bin/activate уже заблокировали на законодательном уровне и обязательно нужно придумывать uv activate? Если нужно что то запустить всегда есть uv run который незаметно для пользователя активирует окружение при запуске любой команды. А если нужно что то запускать несколько раз и каждый раз лень вводить uv run, все активируется по старинке потому что под капотом там обычный venv и знакомое для всех решение

RaptorTV 24 ноя в 07:54

Расскажите ещё о том, какие общепринятые библиотеки надо выкинуть и какие надо вместо них юзать, я с удовольствием послушаю

Eveneven1 24 ноя в 09:17

А про другие инструменты я и не говорил)

Просто странно вот что:

Статья для начинающих -> новички почитают статью и начнут пользоваться тем что тут написано. И только потом узнают про инструмент, который объединяет несколько инструментов, работает быстрее, активно развивается, на который немало людей переводят сейчас свои проекты и т.д.

andreymal 23 ноя в 11:19

[tool.poetry]

Здесь статья сразу палится, что устарела на год, потому что в Poetry 2.0 этот [tool.poetry] уже положено выкинуть за ненадобностью

вы перечисляете только прямые зависимости

Это принципиально ничем не отличается от вручную написанного requirements.txt

Умные группы

Здесь снова статья палится, что устарела: это уже фича не Poetry, а PEP 735

Семантическое версионирование

caret это конечно удобно, но никто не мешал писать pandas>=1.5.3,<2.0 и в старом добром requirements.txt (а начиная с Poetry 2.0 всё равно именно так и придётся писать, потому что [tool.poetry.dependencies] уже положено выкинуть за ненадобностью)

Lock-файл всегда нужно комитить в репозиторий!

А документация намекает что не всегда

Если работает локально — будет работать и на проде.

Нет, потому что разные ОС никто не отменял (особенно если у разработчиков макбуки)

poetry shell

И здесь статья в третий раз палится, что устарела, потому что эта команда уже давно не существует

FROM python:3.11-slim

Ага, значит статья устарела не на год, а на два года 🙃

но формат записи зависимостей внутри него специфичен именно для Poetry

Здесь статья продолжает палиться, что устарела, потому что уже не специфичен

enamored_poc 23 ноя в 11:27

Спасибо за развернутый комментарий! Чувствуется, что вы уже плотно работаете с Poetry 2.0 и новыми стандартами.

Однако цель статьи — помочь новичкам, которые прямо сейчас сидят на requirements.txt и pip, перейти на более удобный инструмент. Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry] (версии 1.x), и именно с ним читатель столкнется в 99% случаев. Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.

По пунктам:

Lock-файл: Для конечных приложений (а статья ориентирована на них, боты/сайты) комитить лок — это best practice. Для библиотек — да, не стоит, но это отдельная тема.
OS: Лок-файл решает проблему версий пакетов. Проблему бинарных сборок под разные архитектуры решает Docker (о чем и сказано в конце).
Python 3.11: Это актуальный LTS релиз, на котором крутится огромная часть продакшена.

Ваше дополнение про Poetry 2.0 очень ценное, оно показывает вектор развития инструмента. Спасибо!

andreymal 23 ноя в 11:29

Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry]

И не надо делать ситуацию ещё хуже, захламляя интернет ещё одной заведомо устаревшей статьёй, запутывающей новичков

Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.

Грузить их заведомо нестандартным и устаревшим [tool.poetry] — значит отпугнуть запутанностью

griha_shershen 23 ноя в 22:46

Я понимаю что статью уже все привыкли писать нейронкой, но в комментариях то зачем её использовать так явно? Понимаю что может не хватать своих знаний и тут это норм, но весь текст?

RaptorTV 24 ноя в 07:55

Хахахахаа

Да он уже без нейронки жить не может)

iroln 24 ноя в 09:36

Чел, хватит писать комментарии через LLM.

thethee 24 ноя в 22:12

Как же вы задрали уже. Все эти смешные ролики про то что люди не могут общаться и при любом удобном случае пишут в приложение "чатгпт, он написал мне такой то комментарий, как мне ему лучше ответить", уже нихрена не смешные. Иногда хочется чтобы чатгпт сказал "остановись, дурак, и подумай что и зачем ты делаешь. Встань и посмотри в стену 5 минут, поразмышляй о жизни"

rSedoy 23 ноя в 11:40

вот тоже заметил что у этого автора куча всего устаревшего, плюс часто встречает однобокость, например, lock файлы это не только фича poetry и т.п.

kiff2007200 23 ноя в 18:32

Статью нейросеть написала (это очень и очень заметно можно не отрицать) естественно она обучена на старых данных)

AAlx0451 24 ноя в 05:56

она не просто устарела, она явно написана ИИ – больше всего это заметно по ультрапафосным заголовкам типа The Old Way, особенно так любит делать Gemini

AAlx0451 24 ноя в 06:08

кстати, датасет Gemini как раз устарел на год

xenon 23 ноя в 14:35

Можно вручную pip'ом все делать (в virtualenv), можно poetry. еще есть uv, а еще есть hatch/hatchling. Таки что есть самый-самый right-way? (у меня самого куча проектов и каждый по разному сделан, после того как узнал про poetry - что-то и на нем было :-))

Ну и вот эта вот строчка прямо радует:

curl -sSL https://install.python-poetry.org | python3 -

Пакет ведь есть в pypi и можно красиво ставить через pipx: pipx install poetry - и это строчка с офсайта. Зачем советовать такой опасный и грязный метод через curl | python ?

Borankin 23 ноя в 19:03

О боги!!! Я нашёл это крутое объяснение, зачем нужен poetry и чем он лучше pip. Можете смеяться, но не всем это очевидно. Автору респектище!

NightShad0w 23 ноя в 19:32

Для себя нашел следующее решение, не зависящее от вчено-изменяющейся инфраструктуры инструментов. environment.yaml для независимого от хоста окружения и не Pip зависимостей или Pip пакетов, но с бинарными запчастями. Потому что например использовать numpy в Ubuntu AMD CPU, а девелопить в MacOS M4 - то еще развлечение со сборкой из исходников. setup.cfg где отдельно прописаны пакеты для основного модуля, и дополнительные, подлежащих установке через package[extra-name] синтаксис, например pip install -e .[test] сделает текущий модуль доступным для редактирования на месте, установит все нужные запчасти. DevOps (или пользователь) берет модуль, выясняет своими путями какие версии пакетов его устраивают и делает requirements.txt из 10 строк + constaints.txt для своего конкретного деплоя.

andreymal 23 ноя в 19:43

setup.cfg

1) Вы таким образом просто зависите от setuptools

2) Поскольку setuptools давно поддерживает pyproject.toml, ничего не мешает прописать эти зависимости в этот самый pyproject.toml и выкинуть setup.cfg за ненадобностью