Всё вышеперечисленное нередко упоминалось новичками, пытающимися использовать 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.
ссылка на оригинал статьи http://habrahabr.ru/post/218125/
Добавить комментарий