Comments 14
Ну. вообще-то нынче рекомендуется (по возможности) использовать pyproject.toml. Cм. https://peps.python.org/pep-0518/ и прочие из этой серии. По возможности, это если не нужно, например, имплементировать команду setup.py clean, или собрать С/C++ extension.
ну конечно, еще в 2016 году. pyproject.toml и setup.cfg
А можете подсказать, чем именно отличается pyprojects.toml, который создает популярный инструмент poetry от того pyprojects.toml, который упоминается в PEP-0518 ? У меня в пет-проектах прижился poetry и мне он нравится. Поэтому хотелось бы лучше понимать возможные риски
Я, прошу прощения, poetry не использую. Хватает стандартных средств.
Тут не совсем корректно говорить об отличии. Poetry просто следует этому стандарту.
PEP 518 очень простой. Он лишь задаёт список зависимостей для системы сборки (обычно там одна зависимость — сама система) и указывает, что все свои настройки система должна хранить в tool.ИМЯ. В случае Poetry это tool.poetry.
Технически никто не мешает использовать одновременно две системы сборки (например, Poetry и Flit) используя один и тот же project.py. Правда смысла в этом не очень много. Разве что на время переходного периода.
Ну и инструменты вроде black, bandit, pytest могут хоанить свои настройки там же.
А вот в чём Poetry стандартам не следует, так это в PEP 621. Этот стандарт говорит, что все метаданные должны храниться в таблице project включая зависимости. Poetry же для зависимостей использует собственную таблицу tool.poetry.dependencies. Более того, он использует нестандартный спецификатор версий (символ ^), не предусмотренный PEP 508.
В Poetry 2.0 скорее всего появится поддержка PEP 621, но ценой отказа от нестандартных элементов.
Наиболее полно стандарты сейчас поддерживает разве что Hatch (что неудивительно, так как он теперь проект PyPA). Но это не значит, конечно, что нужно немедленно на него переходить. Всё зависит от проекта и того, что именно нужно для его разработки и сборки.
5. Установка колеса
Если запустить make build, программа использует файл setup.py, чтобы создать дистрибутив колеса.
Зачем телеге питону пятое колесо?)
Вместо setup.py я бы посоветовал использовать Poetry или Hatch. (Я долгое время пользовался Poetry, но в последнее время больше склоняюсь к Hatch.) Это, кстати, заодно решило бы проблему установки зависимостей, нужных для разработки, и позволило бы избавиться от pipenv (а в случае Hatch, и от Tox).
А вместо Makefile удобно пользоваться Taskfile.
Для тех, кому интересен современный Python, есть неплохая серия статей Hypermodern Python.
Hatch и taskfile развивают одиночки. У второго автор уже неоднократно жаловался на нехватку времени кодить и кажется полгода как отказался от идеи работать над v4. Я бы рекомендовал, если б их взяли под свое крыло какой-нибудь фонд или огранизация. А так есть большие риски через пару лет остаться с легаси один на один. Хотя для пет проекта, где можно переписать весь ci/cd за вечер на чем угодно, наверное, забавно.
Насчёт Taskfile согласен, но даже в нынешнем виде он поприятнее Makefile. Я часто писал мейкфайлы, и после них Taskfile — глоток свежего воздуха.
А Hatch с недавних пор под крылом PyPA. Развивается тоже очень активно несмотря на то, что появился меньше года назад. Poetry уже 4 года, и он тоже на первых порах разрабатывался парой этузиастов.
У Poetry довольно много неочевидных проблем. Например, работа с приватными репозиториями — это боль, так как Poetry не использует pip. А у нас на работе настроена ротация ключей и поддержки чего-то кроме pip ждать не приходится. В итоге пришлось писать свой плагин. Альтернатива — дампить requirements.txt и ставить из него. Ситуация ещё усложнялась тем, что в CI/CD доступ к репозиторию был через прокси, то есть URL другой. И lock-файлы превращались в тыкву, так как нет простого способа подменить адреса.
Были проблемы с установкой пакетов из дополнительных индексов, когда резолвер качал даже версию под Windows работая на Linux. Ну и много других неприятных мелочей.
Справедливости ради, в Hatch вообще нет lock-файлов пока их поддержка не появится в pip. Но он внутри использует pip, то есть более практичен.
И у Poetry, и у Hatch проблемы со сборкой бинарных пакетов. У первого есть build.py, но это нестабильная фича, у второго пока нет внятного решения. Но с другой стороны, свет на них клином не сошёлся. В таких случаях я просто пишу setup.py.
Я бы не сказал, что по возможностям какой-то из этих проектов лучше, но познакомиться с каждым, думаю, всё же стоит.
Хотя для пет проекта, где можно переписать весь ci/cd за вечер на чем угодно, наверное, забавно.
Вряд ли эта статья ориентирована на людей, которые делают сложный CI/CD в большом проекте. :) Так-то у нас на работе одна команда вообще Bazel для питона использует.
import random print(random.randint(-1000000, 1000000)) print(random.randint(-1000000, 1000000)) print(random.randint(-1000000, 1000000)) print(random.randint(-1000000, 1000000)) print(random.randint(-1000000, 1000000))'
Не надо использовать Makefile в экосистеме Python, если только вы не пишете чистые C-API модули без зависимостей и т.д. И даже тогда не надо этого делать...
Есть прекрасный инструмент tox, который не только покрывает возможности Makefile, но и значительно обогащает его питонячьими плюшками (например, под каждую зависимость можно загнать свой набор зависимостей, собирать разом под несколько версий питона, сделать aio/all-in-one окружения, с учётом особенностей).
Makefile на фоне tox'а выглядит бедно, но это не так. Просто это гибкий инструмент для совершенно иной экосистемы.
tox и make — это всё же разные вещи, созданные с разными целями. tox (и аналогичный инструмент nox) — это автоматизация сборки и тестирования проектов на Python в разных окружениях, а make — это инструмент общего назначения для выполнения зависящих друг от друга задач.
tox не перекрывает возможности make. (Тут, конечно, можно поспорить, что такое перекрывает, так как bash-скрипты перекрывают возможности их обоих.) Более того, в документации tox об этом даже написано и предлагается использовать pyinvoke для функционала, аналогичного make. Собственно, tox не то, чтоб очень универсален, иначе бы не появился nox.
Это не значит, что tox — плохой инструмент. Отличный! (Хотя я в какой-то момент перешёл на nox, а потом и на возможности Hatch по созданию матрицы версий.) И действительно, он позволяет делать в пару строк то, что с помощью make сделать сложно.
Просто глаз зацепился за сравнение инструментов из разных категорий.
Давайте по порядку: как статья называется?
Просто вы как будто противоречите, но на деле сказали то же самое, просто другими словами. Tox это инструмент сборки и тестирования, притом отличный. Make, вообще-то это в первую очередь тоже инструмент сборки сишечных исходников (как бы он и заточен под последовательную сборку). Их обоих можно использовать для общего назначения вместо bash (но зачем?). Но это инструменты разных экосистем.
Поэтому я и говорю: не надо тащить инструмент другой экосистемы в Python. Там есть свои.
Просто вы как будто противоречите, но на деле сказали то же самое, просто другими словами.
Я не согласен с утверждением, что tox перекрывает возможности make. А в остальном согласен. Комментарий — это же не обязательно только возражения.
Их обоих можно использовать для общего назначения вместо bash (но зачем?)
tox неудобно использовать для чего-то, не связанного с тестированием питоновского кода для матрицы версий.
Остальную часть комментария я написал для того, чтоб случайный читатель не решил, что я предлагаю везде использовать make.
Учимся создавать пакеты Python