Авторинг Perl модулей

[powerman]

Небольшое примечание для тех, кого раздражает префикс «v» перед номером версии. Если соблюдать некоторые ограничения (минимальный перл 5.10, минимум 3 числа в версии, без альфа-версий), можно этот префикс не указывать:

use 5.010;
our $VERSION = '1.2.3';  # NOT ALLOWED: '1.2', '1.2_3'

Но, по большому счёту, абсолютно не важно, как записана версия внутри модуля, если она корректно работает — её никто кроме автора не видит. А вот как выглядит версия модуля в тегах гита и в имени архива с модулем уже может иметь значение — но обеспечить отсутствие «v» в них это уже задача для утилит авторинга.

[powerman]

Раньше был один сплошной комок — часть описанных в статье задач брала на себя система сборки (Module::Build, например), часть делалась вручную, остальное делать ленились вообще. Сейчас всё становится более цивилизованно, для разных задач появились специализированные инструменты… но разобраться какие инструменты вообще есть, какие заброшены а какие актуальны, чем отличаются и какими лучше пользоваться — очень не просто. Я попытался в статье ответить именно на этот вопрос.

Что до вводной части — предполагалось что это раздел Задачи, в котором описано что обычно требуется делать автору модуля (помимо написания собственно самого модуля, тестов и документации).

[zdm001]

Речь идет о создании дистрибутива софта.

Dist::Zilla применяется для автоматизации различных операций с дистрибутивом (создание, упаковка, тестирование, отправка на cpan).

Все эти операции не так тривиальны, как может показаться, и содержат много рутины.

В общем Dist::Zilla сводит все к выполнению одной команды.

[powerman]

На каком этапе мне понадобится дистзилла?

Понадобится — неправильный термин. Её можно не использовать вообще. Но если её использовать — то она будет использоваться на всех этапах.

А почему я не могу использовать вместо неё мейкмейкер? Что? Это разные инструменты? А в чем разница?

Можете. Просто EUMM решает только часть задач (причём довольно сложным и запутанным образом), поэтому остальные задачи придётся либо выполнять вручную, либо использовать какие-то дополнительные из описанных в статье утилит (например, cpan-uploader для автоматического заливания дистрибутива с модулей созданного EUMM на PAUSE).

А авторинг — это что вообще такое

Уже ответил.

Кто на ком сидит в этой мешанине?

Сложно сказать. Есть много достаточно разных задач. Есть куча утилит, многие из которых пытаются с переменным успехом решать некоторые из этих задач. Естественно, функциональность многих утилит пересекается. Плюс нередко одни из них используют внутри себя другие.

По большому счёту, Вам не должно быть важно кто на ком сидит. Вам нужно сначала сделать выбор между использованием одной утилиты для решения всех (или практически всех — кроме создания скелета нового модуля) задач, или использованием отдельных утилит для разных задач. В первом случае вопрос «кто на ком сидит» отпадёт сам т.к. останется только одна утилита. Во втором просто идёте последовательно по списку всех задач и для каждого следующего шага выбираете подходящую утилиту — которая может заодно решать и другие задачи плюс к текущей, таким образом закрыв собой не одну а несколько задач. Продолжать пока либо не найдёте утилиты для всех задач либо не решите, что оставшиеся без утилит задачи проще делать вручную.

[powerman]

В контексте перл-модулей утилита для авторинга — это программа помогающая автору создавать и подготавливать к распространению перл-модули. Все задачи перечисленные в том разделе относятся именно к процессу авторинга.

Утилиты, описываемые в статье до раздела Авторинг / Authoring решают только отдельные подзадачи процесса авторинга, а описанные в этом разделе Dist::Zilla/Dist::Milla/Minilla — все сразу. ShipIt решает вторую половину задач — всё, связанное с выпуском новой версии, но создавать новый модуль он не умеет. Описание App::ModuleBuildTiny демонстрирует, как решит ту же вторую половину задач используя сборную солянку из описанных в статье мелких утилит.

В каком месте раздела «Задачи» применяется, к примеру, Dist::Zilla?

Во всех местах. Dist::Zilla решает все перечисленные в нём задачи.

А авторинг?

Авторинг — это общее название для всех перечисленных в этом разделе задач.

Что вообще такое авторинг?

Это всё то, что Вам нужно делать для того, чтобы сделать доступным свой новый перл-модуль для других (не важно, через выкладывание его на CPAN/DarkPAN или отправку его другому разработчику по email) — всё, кроме собственно написания кода, тестов и документации этого модуля.

[zdm001]

Dist::Zilla — самый гибкий и расширяемый.

Недостаток — использует монстрообразный Moose c миллионом зависимостей. Я бы вообще перенес Moose в разряд deprecated.

Разобраться не так сложно, как кажется. По сути, все, что он делает — последовательно запускает плагины.

[zdm001]

Еще могу добавить, что лучше всего сразу начинать описывать зависимости в cpanfile, из которого они будут экспортироваться в META файлы дистрибутива.
Это самый практичный подход, т.к. не каждый проект — это CPAN дистрибутив и часто надо просто поставить зависимости для кода из репозитория, не собирая и устанавливая его.

[zdm001]

Dist:::Milla — это просто сконфигурированный профиль Миагавы для Dist::Zilla.
Никакой особой документации для него нет.
В него зашито использование git и github, кому-то может не подойти.

[powerman]

Dist:::Milla — это просто сконфигурированный профиль Миагавы для Dist::Zilla.

Да, но… это достаточно популярный профиль, плюс он построен на нетипичном для большинства профилей Dist::Zilla принципе — работать привычным для авторов не использовавших Dist::Zilla способом, получая нужные ему метаданные из кода/документации модуля вместо того, чтобы брать их из конфига Dist::Zilla и генерировать на их базе часть кода и большую часть документации модуля. Помимо того, что, на мой взгляд, это более разумный подход в принципе, как минимум он сильно упрощает порог входа при попытке начать использовать Dist::Zilla.

Никакой особой документации для него нет.

Ну, например, есть screencast. Но ещё важнее то, что я описал выше — привычный стиль работы с модулем, который не нужно специально документировать.

В него зашито использование git и github, кому-то может не подойти.

Его наверняка можно переключить на использование Mercurial. А что касается GitHub — по большому счёту ради него всё и затевалось. Один только перенос багтрекера с RT стоит того, чтобы всем этим заморочиться. Плюс намного легче отправлять и принимать pull-request-ы, чем вручную сделанные патчи. Плюс возможность устанавливать любую версию прямо из репозитория через cpanm, без заливания на CPAN. Автоматический прогон тестов через Travis CI до выкладывания на CPAN. Контроль покрытия тестами через Coveralls. … В общем, кому-то он, конечно, не подойдёт, но для многих он сильно упрощает работу.

[zdm001]

Отключить гит там — это сделать свой профиль. Это будет уже не дистмилла.
Кстати, популярных профилей много, посмотрите на cpan Dist::Zilla::PluginBundle::

[powerman]

Много — это сколько? Если посмотреть по «плюсикам» на metacpan, то список 162 бандлов вырождается в:

1. 32 — Dist::Zilla::PluginBundle::Git
2. 16 — Dist::Zilla::PluginBundle::Milla
3. 12 — Dist::Zilla::PluginBundle::GitHub
4. 6 — Dist::Zilla::PluginBundle::DAGOLDEN
5. 6 — Dist::Zilla::PluginBundle::TestingMania

При этом Git полностью входит в Milla, функциональность GitHub тоже в Milla реализована, хотя и немного иначе. Что касается подборки Голдена — я его очень уважаю, но он как раз использует зиллу совершенно типичным для неё образом, генерируя половину модуля автоматически из мета-данных — что противоположно подходу миллы. А вот к последнему стоит присмотреться внимательнее — возможно его стоит использовать вместе с миллой, спасибо за наводку. :)

Что касается «уже не милла» — не согласен. Милла — это не конкретная подборка плагинов, высеченная в граните. Это определённая идеология, подход. Плюс базовый набор достаточно неплохо настроенный по умолчанию. Если миллу не менять под себя — в чём тогда вообще смысл с ней связываться если намного проще поставить вместо неё миниллу?

[zdm001]

Минилла не настраивается, гит вшит.

Мне гит не нужен, например, я меркуриал использую.

У каждого серьезного контрибъютора свой профиль.

Переписал бы кто-то Dist::Zilla на Moo. Сразу бы кол-во зависимостей упало в 2 раза.
Кроме этого в ней есть архитектурный баг — при старте загружаются сразу все плагины, которые установлены, а не только те, которые необходимы для выполнения текущей команды. Такого я от Ricardo Signes не ожидал.

[powerman]

Минилла не настраивается, гит вшит.

В неё для этой цели входит PluginRemover, так что можно отключить плагины Git и подключить аналогичные для Mercurial. Теоретически — на практике я этого не проверял, возможно будут какие-то нюансы с порядком вызова плагинов.

Вообще я Вас хорошо понимаю — сам до недавнего момента использовал исключительно Mercurial. Но суровая правда жизни в том, что Git победил. :( Так что можно продолжать любить Mercurial, но Git всё-равно необходимо хорошо знать и уметь использовать. А учитывая, что главное достоинство Mercurial — это юзабилити: его можно вполне полноценно использовать интуитивно, не тратя время на его изучение, вникание во внутреннее устройство репозитория, etc. — то после того, как потрачено время на полноценное изучение Git, основная причина продолжать использовать Mercurial как-то теряет актуальность. Когда разберёшься с Git и привыкнешь думать в терминах операций над репозиторием, а не над своим кодом, он становится вполне удобен.

[zdm001]

Авторитет Торвальдса вывел Git в топ.

Жаль, mercurial, объективно, удачнее.

Вообще, гит нужен только из-за популярности гитхаба. Если атлассиан вломит денег в bitbucket — победит меркуриал.

[powerman]

А при чём тут гитхаб? С ним абсолютно без проблем можно работать через hg-git. И не думаю, что деньги теперь уже помогут — последний опрос на хабре показал порядка 70% гит и 15% меркуриал вроде бы.

Плюс, если с гитом уже разобрался, то формат репо у него всё-таки более здравый, и это тоже имеет определённое значение (я немного работал напрямую с репо меркуриала когда добавлял его поддержку в vcprompt).

[zdm001]

Популярность гита напрямую связана с популярностью гитхаба.

Если бы битбакет появился раньше — сейчас бы пропорция была обратной.

hg-git — не всё поддерживает, лучше ставить полноценный гит клиент.

Репо в меркуриале лучше — он хранит диффы, гит — полные копии, его репо растет в размере гораздо быстрее.

[zdm001]

В Milla автоматически генерируется только README, Changes и зависимости из cpanfile.

Это делается стандартными плагинами.

В общем это только профиль, никакой там особой философии нет.

В милле нет особой надобности, т.к. вы наверняка захотите расширить функционал рано или поздно и сделаете свой профиль.

[zdm001]

Да, я свой профиль скопировал из Milla в начале. ;-)

[powerman]

По-моему просто указать url в git-репо вместо имени модуля. Погуглите… вот, например: https://github.com/perl-carton/carton/issues/132

[zdm001]

Нужно, чтобы cpan клиент поддерживал другие репозитории.
cpanm поддерживает только cpan и развиваться больше не будет, на смену ему пришла библиотека Menlo.
На базе Menlo есть многопоточный App::cpm, который может ставить модули с гитаба.
Посмотрите документацию к нему, там все написано.

[zdm001]

Разве?
У меня он ставит большое кол-во модулей со всеми зависимостями, большая часть из которых — рекурсивные.
Без рекурсивных зависимостей он бесполезен.

Он сейчас активно разрабатывается, можно создать issue на гитхабе.
https://github.com/skaji/cpm/issues

[zdm001]

Ну вообще-то cpanfile это частный случай хранения зависимостей.
Зависимости надо экспортировать в meta, чтобы работало везде.