Как заставить "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

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

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

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

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

Answer 2

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

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

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

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