Трудность с поиском необходимых библиотек. Проблемы с универсальной кросс-платформенной сборкой проекта. Разделение и контроль зависимостей.
Всё вышеперечисленное нередко упоминалось новичками, пытающимися использовать D, как значимое препятствие к созданию новых проектов. Популярность таких проектов как NPM и Ruby Gems формируют определённые ожидания у современных программистов. В то же время, мир нативно компилируемых программ имеет свою специфику.
DUB это попытка создать подобный инструмент для программистов на D, проект, который пользуюется огромной популярностью в сообществе и, вероятно, скоро станет официальным.
Описание
DUB это:
- Сборка проекта на различных операционных системах простым
dub build - Автоматическая загрузка указанных зависимости из регистра проектов
- Контроль версий зависимостей
- Публикация своих проектов в регистре для использования сообществом
- Возможность запускать локальные проекты через
dub run, не засоряя систему - Полностью открытая инфраструктура — ничто не мешает запустить свой регистр проектов или же использовать локальные пути
При этом DUB не предоставляет инструментов по дистрибуции и установке программ среди конечных пользователей и не является менеджером пакетов в полном смысле этого слова. Этот инструмент предназначен для облегчения самого процесса разработки и фокусируется исключительно на этом.
Изначально DUB был создан Sönke Ludwig в рамках проекта vibe.d, однако через некоторое время был переписан в качестве самостоятельного проекта и на данный момент является стандартом de facto для проектов на D. Предполагается, что с какого-то момента утилита станет распространятся вместе с компилятором и получит статус стандартного инструмента de jure — эта идея уже предварительно одобрена авторами языка и вопрос исключительно в более стабилизации API / формата проектов.
Установка
Для установки DUB можно использовать один из следующих вариантов:
- Готовые исполняемые файлы: code.dlang.org/download
- Ручная сборка из репозитория: github.com/rejectedsoftware/dub/ (достаточно запустить
build.sh) - Пакеты для Arch Linux и Ubuntu/Debian
По умолчанию, все временные файлы и кэш регистра хранится в ~/.dub или аналогичной директории локального пользователя, прав администратора для работы не требуется.
Использование
Создание проекта
Самый простой способ создать каркас для нового проекта, это использовать подкоманду init:
dub init proj1
find proj1
# proj1/
# proj1/dub.json
# proj1/source
# proj1/source/app.d
cd proj1
dub run
# proj1: ["proj1"]
# Building proj1 configuration "application", build type debug.
# Compiling...
# Linking...
# Running ./proj1
# Edit source/app.d to start your project.
Команда dub run компилирует и запускает текущий проект согласно настройкам из dub.json, файла описания проекта. Обычно компилируются все файлы из подкаталога ./source/, а так же импортируемые ими модули. Команда dub build делает то же самое, но не запускает исполняемый файл.
Добавление зависимостей
Ключевая возможность dub, ради которой он прежде всего и был написан — автоматическая загрузка зависимостей при компиляции. Для этого нужно указать необходимые библиотеки в dub.json:
{
"name": "proj1",
"description": "A minimal D application.",
"dependencies": {
"vibe-d" : ">=0.7.18",
"cerealed" : ">=0.5.0"
}
}
Все зависимости зависимостей будут загружены неявно. При первой сборке приложения в логе действий будет указано, какие пакеты dub загружает и куда они сохраняются. В дальнейшем будет использовать локальный кэш до тех пор, пока не будет изменена версия зависимости в dub.json или же явно вызвана команда dub upgrade.
В коде самого приложения можно импортировать любые модули из библиотек-зависимостей, не прилагая никаких дополнительных усилий. Генерация необходимых флагов компилятора выполняется самим dub.
module app;
import vibe.d; // just works
Зависимостями могут быть не только библиотеки, но и приложения. В таком случае они будут скомпилированы перед вашим проектом и доступны для использования через dub:
dub run <package name> <application arguments ...>
Дополнительные конфигурации. Тестирование.
Команда dub test скомпилирует и выполнит все юнит-тесты вашего приложения (имеется в виду нативная возможность D: inline unittests). Однако обычно хочется держать тесты более высокого уровня, например, интеграционные, отдельно от основного приложения. Это можно добиться, использовав такую возможность dub.json, как конфигурации:
{
"name": "proj1",
"description": "A minimal D application.",
"sourcePaths" : [ ],
"configurations" : [
{
"name" : "app",
"targetType" : "executable",
"sourcePaths" : [ "./source" ],
},
{
"name" : "tests",
"sourcePaths" : [ "./tests" ],
"targetType" : "executable",
"targetName" : "app-tests",
}
]
}
find ./
# ./dub.json
# ./source
# ./source/app.d
# ./tests
# ./tests/app.d
dub build --config=tests
dub build --config=app # default
По сути, конфигурация — это просто именованый блок опций. В только что приведённом примере используется такой параметр dub.json, как sourcePaths — список директорий с исходниками для используемой конфигурации. По умолчанию в этом списке всегда есть директория "./source", поэтому необходимо сбросить этот параметр в глобальной секции dub.json:
"sourcePaths" : [ ]
Первая из конфигураций в списке всегда используется как конфигурация по умолчанию, поэтому практично использовать её для параметров обычной сборки приложения. В случае, если используется только одна конфигурация, само собой, все эти параметры можно просто указывать в глобальной секции.
Исходники проекта-примера можно и нужно потрогать: github.com/Dicebot/examples/tree/master/dub/proj1
Больше информации
Приведённой выше информации должно хватить для конвертации большинства простых проектов. Для удовлетворения реальных рабочих потребностей, конечно же, может понадобиться куда больше. Рекомендации для дальнейшего изучения:
Наиболее полное описание формата dub.json: code.dlang.org/package-format
Подборка примеров в репозитории проекта: github.com/rejectedsoftware/dub/tree/master/examples
Вопросы / предложения / пожелания: forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
… а так же задавайте вопросы здесь.
Должен предупредить, что вся инфраструктуры развивается усилиями сообщества и пакеты, доступные через регистр, не модерируются. Лучшее, что можно сделать при обнаружении проблем с конкретным пакетом — написать об этом его автору или завести соответствующий Issue в репозитории проекта.
Happy coding.
Автор: Dicebot
