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

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

0 голосов
/ 02 февраля 2019

Это относится к прежнему вопросу о 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-зависимости.

Что мне нужно

Итак, мне нужен какой-то spec / 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 не содержит комментариев, что, по моему мнению, не допускается для любого вида описания, поддерживаемого людьми.

Вопросы

  1. Итак, какой формат / спецификацию я могу использовать для ручного описания некоего абстрактного дистрибутива с использованием некоторого имени и версии, включая его дополнительные функции и зависимости?В значительной степени то, что кажется возможным уже с CPAN::Meta::Spec, только те зависимости уровня пакета кажутся мне слишком низкими на данный момент.

  2. Какой инструмент следует использовать для разрешения зависимостей на основе первогоspec и поддерживает различные исходные репозитории для зависимостей, таких как APT, PPM и SVN?

  3. С появлением таких вещей, как Ansible, стоит ли вообще поддерживать какое-то специфичное для Perl описание?или нужно просто использовать Ansible для описания зависимостей и позволить Ansible предоставить все те, которые используют плагины или что-то еще?

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

1 Ответ

0 голосов
/ 02 февраля 2019

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

При использовании ExtUtils :: MakeMaker, META_MERGE дает вамдоступ к полям из META spec , которые позволяют вам указать информацию, которую вы хотите указать.Следующий фрагмент из 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,
         },
      },
   },
},

Консультируйтесь this для полной prereqs спецификации.

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

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

...