Как управлять зависимостями в Perl ВЫШЕ уровне пакета и БЕЗ ориентации на CPAN?

Question

Как управлять зависимостями в Perl ВЫШЕ уровне пакета и БЕЗ ориентации на CPAN?

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

Мой вариант использования

У меня есть разные Perl-приложения, содержащие множество пакетов, в зависимости от некоторых общесистемных утилит и, конечно, сторонних пакетов. Эти приложения могут предоставлять различные функции в зависимости от конфигурации среды выполнения и зависимости в зависимости от этих функций. Кроме того, если доступны автоматические тесты, они могут также вводить зависимости, а в самом последнем примере - те зависимости, которые уже доступны по умолчанию в ActiveState Perl 5.22 для Windows, где в Ubuntu 16.04 их необходимо было установить с помощью APT.

Мои собственные приложения и утилиты поддерживаются с помощью Subversion и репозиториев, по крайней мере, частично общедоступных для клиентов. Сторонние пакеты предпочитают обслуживать менеджер пакетов ОС, такой как APT или дистрибутив Perl, например PPM для ActiveState Perl в Windows. Только если какая-то зависимость недоступна таким образом, CPAN вступает в игру.

Чего бы я хотел достичь...

... описывает мои приложения и общесистемные утилиты с их зависимостями таким образом, чтобы я мог различать, например, время выполнения от разработки или тестов, и иметь возможность различать дополнительные функции и их зависимости. Кроме того, я хотел бы сохранить некоторые репозитории, где, например, можно загрузить мои собственные приложения и общесистемные утилиты.

Чего я не хочу...

... должен поддерживать в нескольких местах каждый отдельный пакет, который я использую, потому что это не имеет особого смысла для меня. APT не обязательно устанавливает отдельные пакеты Perl, а вместо этого представляет собой некий дистрибутив более высокого уровня, содержащий несколько таких пакетов, например, полное приложение. Если вводятся зависимости, разработчики должны в любом случае проверить, доступны ли они на всех представляющих интерес платформах, что необязательно, и как они распределяются на каждой платформе, например, APT, PPM или CPAN. Таким образом, зависимости от отдельных пакетов не могут быть легко введены без проверки того, как эти пакеты распространяются на какой платформе. Поэтому для моих потребностей вполне достаточно управлять зависимостями ВЫШЕ уровня пакета, что в большинстве случаев поддерживается на платформах.

Кроме того, вот как, например, работают Maven и Gradle: один не зависит от отдельных классов, таких как org.apache.commons.lang3.AnnotationUtils или же org.apache.commons.io.ByteOrderMark, но в дистрибутивах, содержащих такие классы, как Apache Commons Lang и Apache Commons IO в какой-то конкретной версии. Хотя отдельные классы в конечном итоге импортируются в некоторый класс, само описание проекта и его зависимости не содержат такого уровня детализации. Я не понимаю, почему я должен погружаться глубже в Perl, если он хорошо работает для Java, и если мне все равно нужно проверить на уровне распространения, можно ли вообще выполнить Perl-зависимости.

Что мне нужно

Итак, мне нужна некоторая спецификация /DSL, чтобы описать мой проект с каким-то именем, номером версии, его зависимостями и, скорее всего, разными репозиториями, откуда брать вещи. Такой репо будет моим собственным SVN-репозиторием или концепциями, такими как APT или PPM, в лучшем случае даже с дополнительными репо для них, если кто-то решит разместить их. В конце концов, некоторые инструменты, такие как Ansible, следует использовать для установки какого-либо моего приложения, в то же время имея возможность автоматически обрабатывать зависимости, используя плагины или дополнительные инструменты или что-то еще, в зависимости от спецификаций в каждом приложении / проекте.

Что я нашел до сих пор

Для Perl это привело меня к cpanm, cpanfile и CPAN:: Meta:: Spec, которые способны отличать время выполнения от теста, поддерживать дополнительные функции и т. Д. Последний может даже моделировать различные репозитории. Но оба, похоже, поддерживают зависимости от пакета, а не какой-то более высокий уровень распространения. Однако можно обойти это, используя некоторые пакеты, выступающие в качестве заполнителя для дистрибутивов. Например, создавая sysutils.pm содержащий package sysutils; и определение только некоторой версии. Приложения могут зависеть от этого пакета, используя указанные выше форматы.

Недостатки, признанные до сих пор

Но люди, например, рекомендуют не писать CPAN::Meta::Spec вручную, но вместо этого используйте некоторые инструменты для сборки и разработки. Проблема с этим заключается в том, что некоторые / большинство считаются устаревшими из-за самой ссылки на блог или других источников, а некоторые примеры даже приводятся вручную. CPAN::Meta::Spec только эти инструменты в конце. А если нет, то иногда они просто ожидают CPAN::Meta::Spec в некотором произвольном формате конфигурации, который, кажется, не так хорошо определен, как сама спецификация. Так зачем вообще использовать эти инструменты вместо написания спецификации вручную?

Даже CPAN::Meta::Spec само по себе кажется проблематичным, так как самая последняя версия 2, кажется, предпочитает JSON по какой-то недокументированной причине. Это плохое решение для ручной записи и поддержания этой спецификации, конечно, потому что JSON не хватает комментариев, которые, по моему мнению, не подходят для любого вида описания, поддерживаемого людьми.

Вопросы

Итак, какой формат / спецификацию я могу использовать, чтобы вручную описать какой-то абстрактный дистрибутив, используя некоторые имя и версию, включая его необязательные функции и зависимости? В значительной степени то, что кажется возможным с CPAN::Meta::Spec уже только те зависимости уровня пакета кажутся мне слишком низкими на данный момент.
Какой инструмент следует использовать для разрешения зависимостей на основе предыдущей спецификации и поддерживает различные репозитории для таких зависимостей, как APT, PPM и SVN?
С такими вещами, как Ansible, стоит ли вообще поддерживать какое-то специфичное для Perl описание или нужно просто использовать Ansible для описания зависимостей и позволить Ansible предоставлять все те, которые используют плагины или что-то еще?

Спасибо за ваши предложения!

0

perl dependencies dependency-management build-tools

Источник

user2055163 02 фев '19 в 10:17

1 ответ

Другие вопросы по тегам perl dependencies dependency-management build-tools

user589924 02 фев '19 в 18:08 2019-02-02 18:08 · Answer 1 · 2019-02-02 18:08

Я хочу смоделировать зависимости от того, что CPAN::Meta::Spec вызывает распределение

При использовании ExtUtils::MakeMaker, META_MERGE дает вам доступ к полям из спецификации META, которые позволяют вам указать информацию, которую вы хотите указать. Следующий фрагмент из DateTime::Format::Atom демонстрирует это:

META_MERGE  => {
   'meta-spec' => { version => 2 },

   prereqs => {
      configure => {
         requires => {
            'ExtUtils::MakeMaker'       => 6.74,
         },
      },
      runtime => {
         requires => {
            'strict'                    => 0,
            'version'                   => 0,
            'warnings'                  => 0,
            'DateTime'                  => 0,
            'DateTime::Format::RFC3339' => 0,
         },
      },
      test => {
         requires => {
            'Test::More'                => 0,
         },
      },
      develop => {
         requires => {
            'FindBin'                   => 0,
            'Pod::Coverage'             => 0.18,
            'Test::Pod::Coverage'       => 1.08,
         },
      },
   },
},

Обратитесь к этому для полного prereqs спекуляция

Но оба, похоже, поддерживают зависимости от пакета, а не какой-то более высокий уровень распространения."

Вы суетитесь ни о чем. Неважно, что вы должны использовать Foo::Bar вместо Foo-Bar.