Pull to refresh

Менеджер пакетов для .NET

Reading time 3 min
Views 2.5K
Менеджеры пакетов в том или ином их проявлении есть практически везде: Gems и Rip для Ruby, Maven для Java и море разливенное для различных дистрибутивов Linux и Unix. И только .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!
Tags:
Hubs:
+15
Comments 37
Comments Comments 37

Articles