jpm, project.janet и публикация

Для проекта из нескольких файлов и с зависимостями нужен jpm. Его конфигурация написана теми же скобками, что и остальной код, и это не случайность: project.janet просто выполняется.

project.janet

У тебя три файла и зависимость от spork. Запускать это стало неудобно, поставить зависимость некуда, а отдать другому нельзя. С этого места начинается jpm и его конфиг:

(declare-project
  :name "my-library"
  :description "Пример пакета"
  :author "Имя Автора"
  :license "MIT"
  :url "https://github.com/username/my-library"
  :dependencies ["https://github.com/janet-lang/spork.git"])

(declare-source
  :source ["src/my-library.janet" "src/utils.janet"])

declare-project описывает пакет, declare-source перечисляет файлы для установки. В зависимостях указан spork, официальная библиотека-спутник Janet: форматтер, сетевой REPL, вспомогательные модули; мы листали её в 31-janet/01 · Зачем Janet. Соседние объявления:

• declare-executable собирает исполняемый файл;
• declare-native собирает модуль на C, разберём в уроке про FFI;
• declare-binscript ставит скрипт в bin.

Собери конфигурацию под свой случай и посмотри, какие команды к ней прилагаются:

Команды

jpm deps        # поставить зависимости из project.janet
jpm build       # собрать
jpm test        # прогнать всё из test/
jpm install     # установить в систему
jpm clean       # убрать артефакты

jpm test выполняет каждый .janet-файл в каталоге test/. Ненулевой код возврата любого из них означает провал. Никакого фреймворка тут нет, и это одновременно достоинство и ограничение: подробнее в уроке про тестирование.

Локальное дерево зависимостей. Флаг -l (он же --local) держит зависимости в ./jpm_tree вместо системного каталога:

jpm -l deps
jpm -l test

Так разным проектам достаются разные версии библиотек, и права root не нужны. Каталог jpm_tree добавляют в .gitignore. Привычка та же, что с node_modules в проекте на Node, с одним отличием: в jpm_tree лежат исходники и собранные нативные модули, а не дерево из сотен пакетов.

Здесь есть ловушка: после jpm -l deps команда janet main.janet упадёт на импорте, интерпретатор ничего не знает про ./jpm_tree. Запускай через jpm, он подставит правильный путь поиска:

jpm -l janet main.janet

Под капотом это тот же поиск по module/paths, который мы разобрали в 31-janet/16 · Модули: файл, таблица, окружение: jpm выставляет JANET_PATH на локальное дерево.

Публикация

Пакет в Janet это git-репозиторий. Никакого реестра с загрузкой архивов: в зависимостях указывают URL, и jpm его клонирует.

:dependencies ["https://github.com/janet-lang/spork.git"]

Можно закрепить версию тегом или коммитом:

:dependencies [{:url "https://github.com/author/package.git" :tag "v1.2.0"}]

Закрепляй версии для всего чужого. Без тега ты получаешь то, что лежит в HEAD прямо сейчас, а значит сборка невоспроизводима: она зависит от дня, когда её запустили. Это та же проблема, что решают lock-файлы в других экосистемах, только здесь дисциплина целиком на тебе.

Чтобы пакет нашли по короткому имени, его добавляют в реестр Janet. После этого работает:

jpm install package-name

Минимум для публикации: project.janet с declare-project и declare-source, файл лицензии, README и тесты в test/.

Что запомнить

• project.janet это обычный код на Janet, который выполняется.
• declare-project описывает пакет, declare-source перечисляет файлы, рядом живут declare-executable, declare-native, declare-binscript.
• jpm test запускает каждый файл из test/, провал определяется кодом возврата.
• Флаг -l держит зависимости в ./jpm_tree, каталог идёт в .gitignore. Запуск с локальным деревом: jpm -l janet main.janet.
• Пакет это git-репозиторий, зависимость это URL.
• Lock-файла нет, поэтому версии чужих пакетов закрепляй тегом вручную.
• Для короткого имени пакет добавляют в реестр.

Упражнения

Дальше

Организация кода закрыта. Следующий урок про полиморфизм: прототипы таблиц, методы и то, как в Janet выглядит объектно-ориентированный код.