Как заставить "prereqs" из CPAN::Meta::Spec требовать дистрибутив вместо пакета?

Question

Я исследую, как упаковать некоторые из моих Perl-приложений и лучше управлять их зависимостями, чтобы упростить распространение для меня и моих клиентов, что, скорее всего, вообще не включает загрузку в CPAN. Вместо этого я бы предоставил пользовательские репозитории в случае необходимости или, что более вероятно, доступ к SCM, таким как Subversion.

CPAN:: Meta:: Spec, кажется, предоставляет то, что мне нужно, чтобы описать мои приложения, их зависимости и даже где их получить, но меня интересует уровень детализации предварительных условий. Спецификация содержит следующее предложение:

Набор отношений должен быть указан как Карта имен пакетов к диапазонам версий.

Требование пакетов кажется слишком низким уровнем для моих нужд, я бы предпочел вместо этого требовать дистрибутивы. В основном работают инструменты уровня (из моего понимания), такие как Maven и Gradle, например, Apache Commons Lang против Apache Commons IO и т. Д. Вместо отдельных классов, таких как org.apache.commons.lang3.AnnotationUtils или же org.apache.commons.io.ByteOrderMark, OTOH, пример в документации содержит следующие строки:

requires => {
  'perl'          => '5.006',
  'File::Spec'    => '0.86',
  'JSON'          => '2.16',
},

Строка, содержащая perl не похож на пакет для меня, и я не нашел некоторые package perl или же perl.pm где-нибудь в моей системе. Мне кажется, что это обрабатывается по-другому по сравнению с другими примерами.

У меня есть общесистемная папка, содержащая, например, некоторые служебные пакеты, которые кажутся сопоставимыми с некоторыми абстрактными perl мне. Эта папка должна быть определена как один дистрибутив, поддерживать номер версии для всех пакетов в этой папке и, следовательно, должна позволять другим приложениям require все это дело Если я правильно понимаю документы, мне нужно создать не только META.yml в папке, но дополнительно некоторые, например, sysutils.pm содержащий package sysutils; и определение какой-то версии.

Есть ли способ избежать создания этого файла и действительно require только сам дистрибутив?

META.yml уже содержит имя и версию самостоятельно, так что выглядит как-то абстрактно require теоретически. Я не вижу необходимости добавления дополнительного .pm -файл, представляющий сам дистрибутив только для разрешения require работать. В моем случае это не содержало бы никакой бизнес-логики.

Спасибо!

Answer 1

Это действительно не то, что вы хотите сделать. Вы хотите предварительно запросить то, что вам действительно нужно. Так, например, если вам нужно File::Specэто то, что вам нужно, независимо от того, идет ли оно из ядра Perl или из отдельного дистрибутива CPAN.

Я видел случаи, когда определенные модули перемещались из CPAN в ядро ​​или наоборот. Требуя модуль напрямую, вам не нужно поставлять новые выпуски ваших зависимых дистрибутивов просто потому, что кто-то, от кого вы зависите, изменил свой метод распространения.

Я также видел случаи, когда определенные модули отделялись от своих исходных дистрибутивов, когда было определено, что они ценны как отдельные модули. Зависимость от модуля означает, что вы больше не перетаскиваете кучу других модулей для простой зависимости.

То, что вы более или менее ищете, сродни Task::* модули. Никакой реальной логики в большинстве из них, просто список дальнейших зависимостей.

Answer 2

Система зависимостей Perl полностью работает с именами пакетов на нескольких уровнях. При загрузке дистрибутива CPAN каждый пакет в нем индексируется с помощью PAUSE, который также проверяет, есть ли у загрузчика разрешения для этого пакета, и имеет ли пакет более новую версию, чем индексируемый в настоящее время пакет. Ни одна из этих проверок не заботится о распределении в целом (хотя индексатор выполняет другие проверки на этом уровне).

Затем, когда клиент CPAN видит зависимость или вы указываете ему установить что-либо, он проверяет индекс для этого имени пакета, который сообщает ему, какой выпуск дистрибутива установить. Если это зависит от определенной версии, это проверяется по $VERSION объявлен в этом пакете, если он у вас установлен; тогда как после установки дистрибутива его "версия" больше не отслеживается. Уровень распространения практически не имеет смысла, за исключением того, что в конечном итоге он загружается и устанавливается для удовлетворения этих зависимостей. Это важно, потому что модули могут и действительно перемещаться между дистрибутивами, сохраняя приращения своих версий, а индекс пакета всегда сообщит вам, какой дистрибутив получить нужную версию.

Как вы заметили, perl зависимость странная. Это особый случай, который существовал всегда, в качестве соглашения о том, какая версия Perl вам требуется, вы объявляете требование времени выполнения: perl, Это не индексированный модуль, и каждый клиент CPAN и другие потребители особых метаданных CPAN используют его, чтобы либо игнорировать его, либо рассматривать его как минимальную версию Perl, а не как нечто, что можно установить. Нет никакого способа расширить это для работы с дистрибутивами в целом, и было бы плохой идеей попробовать.

В качестве дополнительного примечания мета-спецификация CPAN является спецификацией для файла с именем META.json включены в дистрибутивы CPAN (META.yml является устаревшей версией), но этот файл автоматически создается вашим авторским инструментом. Он никогда не должен создаваться вручную, хотя ваш инструмент разработки может вручную добавить определенные ключи (в этом случае важно прочитать спецификацию), включая prereqs, См. Сообщение в блоге neilb о том, как указать зависимости для различных инструментов разработки, которые затем перенесут их в сгенерированный файл META, а также как использовать cpanfiles для определения зависимостей в целом.