Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI

В этом примере есть две основные зависимости и одна зависимость разработки. Ключи на карте представляют имя зависимости, а значение каждого ключа — это еще одно сопоставление, определяющее информацию о том, как ее разрешить. Чаще всего вы можете использовать один из вспомогательных ключей: 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 завершится неудачно.