Материал, перевод которого мы сегодня публикуем, посвящён рассказу об инструментальных средствах, используемых при создании Python-приложений. Он рассчитан на тех программистов, которые уже вышли из разряда начинающих, но пока не добрались до категории опытных Python-разработчиков.
Тем, кому не терпится приступить к практике, автор предлагает использовать в существующих Python-проектах Flake8, pytest и Sphinx. Он, кроме того, рекомендует взглянуть на pre-commit, Black и Pylint. Тем, кто планирует начать новый проект, он советует обратить внимание на Poetry и Dependabot.
Обзор
Мне всегда было сложно сформировать объективное мнение о «передовых практических методах» разработки на Python. В мире технологий то и дело возникают некие популярные течения, нередко существующие недолго. Это усложняет выделение «полезного сигнала» из информационного шума.
Свежайшие инструменты часто хороши только, так сказать, на бумаге. Способны ли они реально чем-то помочь программисту-практику? Или их применение ведёт лишь к внедрению в проект чего-то нового, работоспособность чего надо поддерживать, что несёт в себе больше сложностей, чем пользы?
У меня не было чёткого понимания того, что именно я считал «передовыми методами» разработки. Полагаю, я находил что-то полезным, основываясь, в основном, на эпизодических свидетельствах «полезности», да на случайных упоминаниях этого в разговорах. В последние пару недель я решил навести порядок в этом вопросе. Для этого я начал анализировать все шаблоны Python-проектов, которые мог найти (речь идёт о шаблонах, используемых утилитой командной строки cookiecutter для создания на их основе Python-проектов).
Мне казалось, что очень интересно узнать о том, какие вспомогательные инструменты авторы шаблонов считают достойными того, чтобы эти инструменты попадали бы в новые Python-проекты, создаваемые на основе этих шаблонов.
Я проанализировал и сопоставил 18 самых популярных проектов шаблонов (от 76 до 6300 звёзд на GitHub), уделяя особое внимание тому, какие именно вспомогательные инструменты в них используются. Результаты этого анализа можно найти в данной таблице.
Ниже я хочу поделиться основными выводами, которые я сделал, анализируя популярные шаблоны.
Стандарты де-факто
Инструменты, о которых пойдёт речь в этом разделе, включены в более чем половину шаблонов. Это означает, что они воспринимаются как стандартные в большом количестве реальных Python-проектов.
▍Flake8
Я уже довольно давно пользуюсь Flake8, но я не знал о том доминирующем положении в сфере линтинга, которое занимает этот инструмент. Я думал, что он существует в условиях некоей конкуренции, но подавляющее большинство шаблонов проектов использует именно его.
Да это и неудивительно. Сложно что-то противопоставить удобству линтинга всей кодовой базы проекта за считанные секунды. Тем, кто стремится пользоваться суперсовременными разработками, можно порекомендовать взглянуть на wemake-python-styleguide. Это нечто вроде «Flake8 на стероидах». Это средство вполне может способствовать переводу в разряд устаревших других подобных инструментов (вроде Pylint).
▍Pytest и coverage.py
В подавляющем большинстве шаблонов используется pytest. Это ведёт к сокращению использования стандартного фреймворка для написания тестов unittest. Pytest выглядит ещё привлекательнее, когда его объединяют с tox. Именно так и сделано примерно в половине шаблонов. Покрытие кода тестами чаще всего проверяют с помощью coverage.py.
▍Sphinx
В большинстве шаблонов для генерирования документации используется Sphinx. К моему удивлению, MkDocs применяется для этой цели достаточно редко.
В результате можно сказать, что если вы не пользуетесь в своём текущем проекте Flake8, pytest и Sphinx, то вам стоит подумать об их внедрении.
Перспективные инструменты
В этом разделе я собрал те инструменты и приёмы работы, использование которых в шаблонах наводило на мысль о неких трендах. Речь идёт о том, что хотя всё это и не появляется в большинстве шаблонов проектов, во многих достаточно свежих шаблонах это встречается. А значит — на всё это стоит обратить внимание.
▍Pyproject.toml
Применение файла pyproject.toml предложено в PEP 518. Это современный механизм указания требований по сборке проекта. Он применяется в большинстве достаточно молодых шаблонов.
▍Poetry
Хотя в экосистеме Python не всё благополучно в плане хорошего инструмента для управления зависимостями, я, с осторожным оптимизмом, полагаю, что аналогом npm из мира JavaScript в мире Python может стать Poetry.
С этой моей идеей, как кажется, согласны самые молодые (но, несмотря на это, популярные) шаблоны проектов. Правда, стоит сказать о том, что если некто работает над какой-то библиотекой, которую он может планировать распространять через PyPI, то ему, всё равно, придётся пользоваться setuptools. (Надо отметить, что после публикации этого материала мне сообщили, что это, по видимому, уже не проблема).
Кроме того, будьте осторожны, если ваш проект (то же относится и к зависимостям) полагается на Conda. В этом случае Poetry вам не подойдёт, так как этот инструмент, в его текущей форме, привязывает разработчика к pip и к virtualenv.
▍Dependabot
Dependabot регулярно проверяет зависимости проекта на предмет их устаревания и пытается помочь разработчику, автоматически открывая PR.
Лично я в последнее время вижу этот инструмент чаще, чем прежде. Мне кажется, что он представляет собой отличное средство, добавление которого в проект сказывается на проекте весьма позитивно. Dependabot позволяет снижать риски безопасности благодаря тому, что он подталкивает разработчиков к поддержанию зависимостей в актуальном состоянии.
В результате советую вам не выпускать из вида Poetry и Dependabot. Рассмотрите возможность внедрения этих инструментов в свой следующий проект.
Личные рекомендации
Анализ шаблонов проектов дал мне несколько двойственное восприятие тех инструментов, которые я перечислю в этом разделе. В любом случае, я хочу использовать этот раздел для того, чтобы рассказать о них, основываясь на собственном опыте. В своё время они мне очень пригодились.
▍Pre-commit
Даже если вы чрезвычайно дисциплинированы — не тратьте силы на выполнение простых рутинных действий вроде дополнительного прогона кода через линтер перед отправкой кода в репозиторий. Подобные задачи можно передать Pre-commit. А свою энергию лучше потратить на TDD и на командную работу над кодом.
▍Pylint
Хотя Pylint и ругают за медленность, хотя этот инструмент критикуют за особенности его настройки, я могу отметить, что он позволил мне вырасти над собой в сфере программирования.
Он даёт мне конкретные указания на те участки кода, которые я могу улучшить, сообщает о том, как сделать так, чтобы код лучше соответствовал правилам. Для бесплатного инструмента одно только это уже очень много. Поэтому я готов мириться с неудобствами, связанными с Pylint.
▍Black
Black на корню пресекает споры, касающиеся того, где в коде надо ставить пробелы. Это оберегает наши команды от пустых разговоров и от бессмысленных различий в файлах, вызванных разными настройками редакторов.
В моём случае это скрашивает то, что лично мне не нравится в Python (необходимость в использовании множества пробелов). Более того, надо отметить, что проект Black в 2019 году присоединился к Python Software Foundation, что говорит о серьёзности и качественности этого проекта.
В результате хочу сказать, что если вы до сих пор не пользуетесь pre-commit, Black и Pylint — подумайте над тем, могут ли эти инструменты принести пользу вашей команде.
Промежуточные итоги
Двенадцать из восемнадцати исследованных шаблонов созданы с использованием фреймворка cookiecutter. У некоторых из тех шаблонов, где этот фреймворк не используется, есть интересные качества.
Но учитывая то, что cookiecutter — это ведущий фреймворк для создания шаблонов проектов, у того, кто решится использовать шаблон, при создании которого cookiecutter не использовался, должны быть на это весьма веские причины. Подобное решение должно быть очень хорошо обосновано.
Тому, кто ищет шаблон для своего проекта, стоит выбрать такой шаблон, который наиболее близко соответствует его собственному взгляду на вещи. Если вам, создавая проекты по некоему шаблону, постоянно приходится их перенастраивать одним и тем же образом, подумайте о том, чтобы сделать форк такого шаблона и доработать его, вдохновившись примерами шаблонов из моего списка.
А если вас тянет на приключения — создайте собственный шаблон с нуля. Cookiecutter — это замечательное явление экосистемы Python, а простой процесс создания Jinja-шаблонов позволит вам быстро и без особых усилий сделать что-то своё.
Бонус: рекомендации по шаблонам
▍Django
Вместе с наиболее популярными Django-шаблонами, рассмотрите возможность использования шаблона wemake-django-template. Он создаёт впечатление глубоко продуманного продукта.
▍Обработка и анализ данных
В большинстве проектов, направленных на обработку и анализ данных, пригодится шаблон Cookiecutter Data Science. Однако дата-сайентистам стоит взглянуть ещё и на Kedro.
Этот шаблон расширяет возможности Cookiecutter Data Science благодаря механизму создания стандартизированных конвейеров обработки данных. Он поддерживает загрузку и сохранение данных и моделей. Эти возможности, весьма вероятно, смогут найти достойное применение в вашем очередном проекте.
Тут мне ещё хотелось бы выразить благодарность создателям шаблона shablona за то, что они подготовили весьма качественную документацию. Она может пригодиться вам даже в том случае, если вы в итоге выберете что-то другое.
▍Шаблоны общего назначения
То, какой шаблон общего назначения выбрать, некоторым образом зависит от того, что именно вы собираетесь на основе этого шаблона разрабатывать — библиотеку или обычное приложение. Но я, выбирая подобный шаблон, вместе с самыми популярными проектами такого рода, очень внимательно присмотрелся бы к Jace's Python Template.
Это — не особенно известный шаблон, но мне нравится то, что в нём есть Poetry, isort, Black, pylint и mypy.
PyScaffold — это один из самых популярных шаблонов, основанных не на cookiecutter. У него имеется множество расширений (например — для Django, и для Data Science-проектов). Он, кроме того, загружает номера версий с GitHub, пользуясь setuptools-scm. Далее, это — один из немногих шаблонов, поддерживающих Conda.
Вот пара шаблонов, в которых используется технология GitHub Actions:
- Шаблон Python Best Practices Cookiecutter, в котором, хочу отметить, имеется большинство моих любимых инструментов.
- Шаблон Blueprint/Boilerplate For Python Projects, который я считаю довольно интересным, так как даваемая им возможность нахождения распространённых проблем с безопасностью с помощью Bandit выглядит многообещающе. Кроме того, этот шаблон отличается замечательной особенностью, которая заключается в том, что настройки всех инструментов собраны в едином файле
setup.cfg.
И наконец — рекомендую взглянуть на шаблон wemake-python-package. Полагаю, сделать это стоит в любом случае. В особенности — если вам нравится Django-шаблон того же разработчика, или в том случае, если вы собираетесь воспользоваться продвинутым wemake-python-styleguide вместо чистого Flake8.
Итоги
После того, как я опубликовал эту статью, я написал о ней Гвидо ван Россуму.
Возможно, вам, как и мне, будет интересен его комментарий. Он сказал, что я забыл про mypy, и что проще работать не со Sphinx, а с Markdown. По поводу Black он отметил, что этот инструмент переоценён и способен принести пользу только в том случае, если члены команды много спорят о стилях. По его словам, тем, кто использует Flake8, Pylint не нужен. О Poetry и Dependabot он не слышал. Кроме того, он посоветовал пользоваться неким CI-решением, вроде Travis-CI, для запуска тестов.
Уважаемые читатели! Какими шаблонами Python-проектов вы пользуетесь?
Автор: ru_vds
