Менеджеры пакетов в том или ином их проявлении есть практически везде: Gems и Rip для Ruby, Maven для Java и море разливенное для различных дистрибутивов Linux и Unix. И только .NET-разработчики по старинке ползают по сайтам в поисках той или иной версии необходимой библиотеки.
Будучи одним из таких разработчиков и устав от постоянных поисков требуемых компонентов, я решил, что с этим пора заканчивать. Результатом такого решения стал таки менеджер компонентов для платформы .NET
Встречайте: octalforty Componento (первая альфа доступна здесь для 32-битных ОС или здесь для 64-битных собратьев). Это, по моим сведениям, первая попытка создания менеджера пакетов для .NET.
Механизм работы, в принципе, не сильно отличается от его аналогов в других средах: есть центральный репозиторий, к которому обращаются клиенты и откуда получают информацию о том, что и откуда загружать. Существенный недостаток заключается в том, что формат пакетов (по сути — zip-архивов) никак не стандартизирован, поэтому по сравнению с тем же Ruby в этом плане везде царит хаос. Но это все наживное (при условии удачного течения дел, разумеется).
Папку, в которую был разархивирован Componento, лучше всего добавить в
Представим, что вы в самом начале разработки проекта и начинаете собирать необходимые библиотеки. Предположим, что структура папок проекта похожа на следующую:
В
Настоящему .NET-разработчику нельзя и шага ступить без юнит-тестов и ORM-средства. Посему, на первом этапе нам потребуются NUnit, NHibernate и Fluent NHibernate. Приступим:
На такую команду Componento вполне резонно ответит тем, что, мол, «No packages installed». Посмотртим, какие компоненты есть на сервере:
Отлично, как раз то, что нужно.
Папка
Командой
Кроме того, Componento умеет устанавливать из репозиториев Subversion, папок и Zip-файлов. К примеру,
И пару слов о зависимостях. Если в корне папке, в которую Componento установит указанный компонент, окажется файл
то Componento рекурсивно установит все зависимости, а впоследствии будет проверять конфликты версий и не даст так просто удалить компонент, если на него есть зависимости.
Их много. Во-первых, нет формата пакета как такового. То есть, абсолютно отсутствуют метаданные о компоненте (разве что есть версия и название). Во-вторых, не до конца продумана работа с локальными папками и архивами. В третьих, пока нет возможности публиковать свои компоненты в центральном репозитории (в задумках как веб-интерфейс, так и отдельный API для публикации компонентов). В четвертых, не оформлена поддержка платформ (к примеру, разделение компонентов на оные для Silverlight, .NET 2.0, .NET 3.0 и т.д.). Ну и в целом — это всего лишь первая альфа.
Я пока не готов выставлять данное творение на суд англоязычной публики; для начала надо получить что-то более существенное. Поесему предложения, пожелания, комментарии и критика приветствуются. Давайте уже построим менеджер пакетов для .NET!
Будучи одним из таких разработчиков и устав от постоянных поисков требуемых компонентов, я решил, что с этим пора заканчивать. Результатом такого решения стал таки менеджер компонентов для платформы .NET
Componento
Встречайте: octalforty Componento (первая альфа доступна здесь для 32-битных ОС или здесь для 64-битных собратьев). Это, по моим сведениям, первая попытка создания менеджера пакетов для .NET.
Механизм работы, в принципе, не сильно отличается от его аналогов в других средах: есть центральный репозиторий, к которому обращаются клиенты и откуда получают информацию о том, что и откуда загружать. Существенный недостаток заключается в том, что формат пакетов (по сути — zip-архивов) никак не стандартизирован, поэтому по сравнению с тем же Ruby в этом плане везде царит хаос. Но это все наживное (при условии удачного течения дел, разумеется).
«Поехали!»
Папку, в которую был разархивирован Componento, лучше всего добавить в
PATH
— дальше будет проще.Представим, что вы в самом начале разработки проекта и начинаете собирать необходимые библиотеки. Предположим, что структура папок проекта похожа на следующую:
В
src
— исходный код самого продукта, в lib
— сторонние библиотеки, ну а в doc
, очевидно, документация.Настоящему .NET-разработчику нельзя и шага ступить без юнит-тестов и ORM-средства. Посему, на первом этапе нам потребуются NUnit, NHibernate и Fluent NHibernate. Приступим:
C:\>cd d:\projects\acme\lib E:\Projects\Acme\lib>componento list
На такую команду Componento вполне резонно ответит тем, что, мол, «No packages installed». Посмотртим, какие компоненты есть на сервере:
E:\Projects\Acme\lib>componento list /remote octalforty Componento 1.0 Alpha 1 Copyright (c) 2009 octalforty studios Downloading 4,3 Kb autofac (1.4.4.561) bltoolkit (3.0) ... fluent-nhibernate (1.0) ... nhibernate (1.2.1) nhibernate (2.1.0) ... nunit (2.5.0.9122) nunit (2.5.1.9189) nunit (2.5.2.9222) ... urlrewriting.net (2.0) zedgraph (5.1.5)
Отлично, как раз то, что нужно.
componento install nunit
— и самый свежий NUnit окажется в папке lib
. Таким же образом устанавливаем nhibernate
и fluent-nhibernate
. В итоге получается вот что:Папка
_componento
— кэш загруженных файлов, а componento.db
— база данных установленных компонентов и их зависимостей.Остальные возможности
Командой
componento install nunit /version 2.5.0.9122
можно было бы установить библиотеку NUnit версии 2.5.0.9122, а командой componento uninstall nunit /force /recursive
удалить NUnit и все зависимости.Кроме того, Componento умеет устанавливать из репозиториев Subversion, папок и Zip-файлов. К примеру,
componento install bltoolkit /source svn+http://bl-toolkit.googlecode.com/svn/trunk/
заберет из указанного репозитория все исходники BLToolkit (префикс svn+
в случае, когда доступ к репозиторию осуществляется через HTTP или HTTPS, обязателен). А команда componento install myproject /source d:\projects\myproject.zip
«установит» архив myproject.zip
.И пару слов о зависимостях. Если в корне папке, в которую Componento установит указанный компонент, окажется файл
dependencies.txt
примерно следующего содержания:nhibernate-linfu file:///e:/lib/nhibernate-linfu
nhibernate-castle file:///e:/lib/nhibernate-castle
то Componento рекурсивно установит все зависимости, а впоследствии будет проверять конфликты версий и не даст так просто удалить компонент, если на него есть зависимости.
Минусы и недоработки
Их много. Во-первых, нет формата пакета как такового. То есть, абсолютно отсутствуют метаданные о компоненте (разве что есть версия и название). Во-вторых, не до конца продумана работа с локальными папками и архивами. В третьих, пока нет возможности публиковать свои компоненты в центральном репозитории (в задумках как веб-интерфейс, так и отдельный API для публикации компонентов). В четвертых, не оформлена поддержка платформ (к примеру, разделение компонентов на оные для Silverlight, .NET 2.0, .NET 3.0 и т.д.). Ну и в целом — это всего лишь первая альфа.
Вместо заключения
Я пока не готов выставлять данное творение на суд англоязычной публики; для начала надо получить что-то более существенное. Поесему предложения, пожелания, комментарии и критика приветствуются. Давайте уже построим менеджер пакетов для .NET!