• Зависимости от среды выполнения

• Зависимости от разработки

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

Оба этих типа зависимостей могут быть указаны в файле shard.yml с помощью сопоставлений dependency и development_dependenties соответственно. Пример таких сопоставлений следующий:

dependencies:

  shard1:

    github: owner/shard1

    version: ~> 1.1.0

  shard2:

    github: owner/shard2

    commit: 6471b2b43ada4c41659ae8cfe1543929b3fdb64c

development_dependencies:

  shard3:

    github: dev-user/shard3

    version: '>= 0.14.0'

В этом примере есть две основные зависимости и одна зависимость разработки. Ключи на карте представляют имя зависимости, а значение каждого ключа — это еще одно сопоставление, определяющее информацию о том, как ее разрешить. Чаще всего вы можете использовать один из вспомогательных ключей: github, bitbucket или gitlab в форме владельца/репо в зависимости от того, где размещена зависимость. Дополнительные ключи для каждой зависимости можно использовать для выбора конкретной версии, диапазона версий, ветки или фиксации, которые следует установить. В дополнение к вспомогательным ключам URL-адрес репозитория может быть предоставлен для Git, Mercurial или Fossil с помощью ключей git, hg и fossil соответственно. Ключ пути также можно использовать для загрузки зависимости по определенному пути к файлу, но его нельзя использовать с другими параметрами, включая версию, ветку или фиксацию.

Настоятельно рекомендуется указывать версии ваших зависимостей. Если вы этого не сделаете, то по умолчанию будет использоваться последняя версия, которая может незаметно вывести из строя ваше приложение, если вы позднее обновитесь до версии, включающей критические изменения. Использование оператора ~> может быть полезно в этом отношении, чтобы разрешить обновления, но не предыдущие определенные второстепенные или основные версии. В этом примере ~> 1.1.0 будет эквивалентно >= 1.1.0 и < 1.2, а ~> 1.2 будет эквивалентно >= 1.2 и < 2.

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

Как только вы обновите файл shard.yml со всеми зависимостями, которые потребуются вашему проекту, вы можете продолжить и установить их с помощью команды установки shards. Это позволит определить версию каждой зависимости и установить их в папку lib/. Отсюда вы можете запросить код, выполнив require “shard1” или любое другое имя осколка в вашем проекте.

Возможно, вы заметили, что Crystal может найти осколок в папке lib/, хотя обычно это приводит к ошибке, поскольку его нигде нет в src/. Причина, по которой это работает, связана с переменной среды CRYSTAL_PATH. Эта переменная определяет местоположение(я), в которых Crystal будет искать необходимые файлы за пределами текущей папки. Например, для меня запуск crystal env CRYSTAL_PATH выводит lib:/usr/lib/crystal. Здесь мы видим, что сначала он пробует папку lib/, а затем стандартную библиотеку Crystal, используя стандартные правила поиска в каждом месте.

В процессе установки также будет создан еще один файл с именем shard.lock. Цель этого файла — обеспечить воспроизводимые сборки путем блокировки версий каждой установленной зависимости, чтобы будущие вызовы shards install приводили к установке тех же версий. Это в первую очередь предназначено для конечных приложений, а не для библиотек, поскольку зависимости библиотеки также будут заблокированы в файле блокировки приложения. Файл блокировки по умолчанию игнорируется системами контроля версий для библиотек, например, при создании нового проекта через crystal init lib lib_name.

Опцию --frozen также можно передать в программу установки shards, что заставит ее установить только то, что находится в файле shard.lock, и выдаст ошибку, если оно не существует. По умолчанию при запуске shards install также будут установлены зависимости разработки. Опцию --without-development можно использовать только для установки основных зависимостей. Опцию --production также можно использовать для объединения этих двух вариантов поведения.

Хотя большинство зависимостей предоставляют только тот код, который может потребоваться, некоторые могут также собрать и предоставить двоичный файл в папке bin/ вашего проекта. Такое поведение можно включить для библиотеки, добавив в ее сегмент что-то похожее на shard.yml файл:

scripts:

  postinstall: shards build

executables:

  - name_of_binary

Хук postinstall представляет собой команду, которая будет вызвана после установки осколка. Чаще всего это просто shards build, но мы также можем вызвать Makefile для более сложных сборок. Однако при использовании перехватчиков postinstall и особенно файлов Makefile необходимо помнить о совместимости. Например, если перехватчик запущен на машине без make или одного из требований сборки, вся команда shards build завершится неудачно.

Затем массив исполняемых файлов представляет, какие из собранных двоичных файлов следует скопировать в проект установки, имена которых соответствуют именам локально созданных двоичных файлов. Параметры --skip-postinstall и --skip-executables, которые можно передать при установке шардов, также существуют, если вы не хотите выполнять один или оба этих шага.

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

Shard зависимости от кода C

До сих пор предполагалось, что устанавливаемые Шарды представляют собой чистые реализации Crystal. Однако, как мы узнали ранее в Главе 7 «Взаимодействие C», Crystal может связываться с существующими библиотеками C и использовать их. Шарды не поддерживают установку библиотек C, необходимых для привязок Crystal. Пользователь, использующий Shard, может установить их, например, через менеджер пакетов своей системы.

Хотя Shards не обеспечивает их установку за вас, он поддерживает ключ информационных библиотек в shard.yml. Пример этого выглядит следующим образом:

libraries:

    libQt5Gui:

    libQt5Help: "~> 5.7" libQtBus: ">= 4.8"

Глядя на это, кто-то, пытающийся использовать Shard, может узнать, какие библиотеки необходимо установить, основываясь на библиотеках C, на которые ссылается Shard. Еще раз: это чисто информационный характер, но вам все равно рекомендуется включить его, если ваш шард привязан к каким-либо библиотекам C.

В большинстве проектов установленные зависимости, скорее всего, со временем устареют, в результате чего приложение потеряет потенциально важные исправления ошибок или новые функции. Давайте посмотрим, как обновить Shards дальше.

Обновление осколков

Программное обеспечение постоянно развивается