Разработка продолжается. Появился более-менее функциональный сайт, где любой желающий (при условии обладания OpenID) может опубликовать компонент на радость остальным разработчикам. Кроме того, как можно видеть на картинке, обогатился формат метаданных и были добавлены маппинги путей для распаковки содержимого архива (долго объяснять -- проще попробовать).
Здравствуйте, Нахлобуч, Вы писали:
Н>Загрузка, традиционно, отсюда.
Вообще идея отличная, но есть нюансы. Всякие gem'ы и ez'ы стали стандартом для платформ и пакеты создают
именно разработчики. Если это будет делать кто попало, то велика вероятность вкомпилить троян себе в приложение.
Как планируется решать эту проблему?
Здравствуйте, Ziaw, Вы писали:
Z>Вообще идея отличная, но есть нюансы. Всякие gem'ы и ez'ы стали стандартом для платформ и пакеты создают Z>именно разработчики. Если это будет делать кто попало, то велика вероятность вкомпилить троян себе в приложение. Z>Как планируется решать эту проблему?
Вообще конечно хотелось бы, чтобы пакеты публиковали именно разработчики -- я задумывался как насчет API для публикации, так и насчет автоматического импорта пакетов из указанного места (а-ля RSS, в котором говорится о том, что такой-то пакет доступен для загрузки), но надо набрать какую-то критическую массу и определенный "авторитет".
Насчет троянов и прочей нечисти: есть мысли о подписывании пакетов (по сути, так, как в gem'ах сделано), но пока, по-моему, рано заставлять это делать.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Вообще конечно хотелось бы, чтобы пакеты публиковали именно разработчики -- я задумывался как насчет API для публикации, так и насчет автоматического импорта пакетов из указанного места (а-ля RSS, в котором говорится о том, что такой-то пакет доступен для загрузки), но надо набрать какую-то критическую массу и определенный "авторитет".
Вобщем да, у меня сразу куча пожеланий по реализации:
Таски для мсбилда и нанта: которые загружают в проект либы нужной версии в нужные папки (без создания подпапок и какой-то базы установленных, или хотя бы чтобы это можно было кастомизировать). Выглядит например так:
Кеш репозитария в каждом проекте не нужен, пусть лежит в темпе или аппдате.
Метаданные каждого компонента компонента должны содержать что-то типа урезанного билдскрипта. При этом дсл скрипта должен быть предельно прост, нужно уметь выкачивать архивы по урлам, распаковывать, копировать файлы в папку назначения, проверять паблик кей сборок, хеши. Это все тоже можно свести к мсбилд таскам, чтобы не изобретать свой язык.
Например так:
componento init
-- создается componento.proj
componento add nhibernate
-- в componento.proj добавляется таск по установке nh (если вместо add написать install, пакет при этом сразу будет установлен)
componento install (== msbuild componento.proj install, установим все компоненты)
Плюсы: либы в VCS больше не нужны (!!! оле, я вижу чудный день, когда качаю только исходники, нажимаю билд и они берут все зависимости из локального кеша)
componento не нужен на целевой машине для билда (правда нужны его таски, тут надо хорошо подумать)
все что происходит открыто и доступно для понимания среднего девелопера, соотвественно легко кастомизируется и внедряется во всякие CI.
собрать пакет для нового компонента становится не просто, а очень просто
достаточно легко собрать универсальный пакет для любой версии либы (или скорее реюз кода похожий на порты FreeBSD)
все форматы открыты и стандартны, sqlite больше не нужен, одной зависимостью меньше
Н>Насчет троянов и прочей нечисти: есть мысли о подписывании пакетов (по сути, так, как в gem'ах сделано), но пока, по-моему, рано заставлять это делать.
Здравствуйте, Ziaw, Вы писали:
Z>Вобщем да, у меня сразу куча пожеланий по реализации:
Отлично! Но прежде всего давай, может быть, определимся, как ты видишь процесс работы с Componento: похоже что твой подход сильно отличается от того, что я себе напредставлял.
Вообще говоря, я хотел сделать инструмент, который облегчал бы поиск библиотек (чтобы не продираться через интернеты в поисках версии NHibernate, совместимой со Spring.NET 1.3.0), а так же их обновление. На что-то типа Maven'а я и не замахивался; это, скорее, .NET-подобие Rip.
По моему разумению, работа протекает следующим образом. Разработчик понимает, что ему нужна какая-то библиотека -- тот же autofac. Он:
В lib\autofac создается определенная структура каталогов, туда разархивируется содержимое загруженного архива, в componento.db прописывается информация о том, что установлен autofac такой-то версии с такими-то зависимостями. Всё это хранится в VCS (да, есть определенные проблемы с бинарным componento.db), интеграция с CI тривиальна (поскольку оной нет -- все библиотеки вот они), никаких дополнительных телодвижений не требуется.
Со временем выходит новая версия autofac. Разработчик
D:\Projects\Project\lib>componento update autofac
При этом проверяются все зависимости, по возможности исключая все конфликтные ситуации, обновляются необходимые сборки и всё.
Z>Таски для мсбилда и нанта: которые загружают в проект либы нужной версии в нужные папки (без создания подпапок и какой-то базы установленных, или хотя бы чтобы это можно было кастомизировать). Выглядит например так:
Z><componento-req package="C5" version="1.0" dst="./lib" />
Насчет тасков ну совершенно непонятно, зачем и почему. А насчет подпапок история отдельная. Сейчас каждый "вендор" творит кто во что горазд. К примеру, архив NUnit'а в качестве корневой папки содержит папку вида "NUnit-x.x.x.x" и если не глядя разархивировать его в lib, то придется править референсы во всех проектах, использующих NUnit. NHibernate же с каждым выпуском архивируется по разному, так что если и его распаковывать "просто в lib", то банально отвалятся референсы на nhibernate.dll. Для того то я и озаботился унифицированой структурой папок и сопоставлениями путей (path-mapping) в манифесте.
Z>Кеш репозитария в каждом проекте не нужен, пусть лежит в темпе или аппдате.
componento.db -- это не кэш, а база данных установленных компонентов, их зависимостей (а в будущем -- и файлов, из которых состоит компонент). Кэш лежит в %ALLUSERSPROFILE%\octalforty\Componento\componento.cache.db
Z>Метаданные каждого компонента компонента должны содержать что-то типа урезанного билдскрипта. При этом дсл скрипта должен быть предельно прост, нужно уметь выкачивать архивы по урлам, распаковывать, копировать файлы в папку назначения, проверять паблик кей сборок, хеши. Это все тоже можно свести к мсбилд таскам, чтобы не изобретать свой язык.
Над этим тоже думал, но исключительно в том ключе, что, к примеру,
сделает check out/export исходников из указанного репозитория и сможет собрать проект. Но для этого я всего лишь планировал указывать в манифесте имя скрипта, который надо выполнять по команде build.
Z>Например так:
componento init
-- создается componento.proj
componento add nhibernate
-- в componento.proj добавляется таск по установке nh (если вместо add написать install, пакет при этом сразу будет установлен)
componento install (== msbuild componento.proj install, установим все компоненты)
Вот это интересно, но непонятно, зачем каждый раз при сборке выкачивать откуда-то зависимости, когда можно банально держать их в VCS. Какие плюсы такого подхода?
Z>либы в VCS больше не нужны (!!! оле, я вижу чудный день, когда качаю только исходники, нажимаю билд и они берут все зависимости из локального кеша)
Уже спросил выше.
Z>все что происходит открыто и доступно для понимания среднего девелопера, соотвественно легко кастомизируется и внедряется во всякие CI.
Сейчас тоже: всё просто лежит себе в lib.
Z>собрать пакет для нового компонента становится не просто, а очень просто Z>достаточно легко собрать универсальный пакет для любой версии либы (или скорее реюз кода похожий на порты FreeBSD)
Не понял.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Отлично! Но прежде всего давай, может быть, определимся, как ты видишь процесс работы с Componento: похоже что твой подход сильно отличается от того, что я себе напредставлял.
Н>По моему разумению, работа протекает следующим образом. Разработчик понимает, что ему нужна какая-то библиотека -- тот же autofac. Он:
Н>
Да, это никак не расходится с моими пожеланиями. Все точно так и сработает. Только кроме инсталяции в рабочую папку он запишет таск установки текущей версии в comonento.proj.
Н>В lib\autofac создается определенная структура каталогов, туда разархивируется содержимое загруженного архива, в componento.db прописывается информация о том, что установлен autofac такой-то версии с такими-то зависимостями. Всё это хранится в VCS (да, есть определенные проблемы с бинарным componento.db), интеграция с CI тривиальна (поскольку оной нет -- все библиотеки вот они), никаких дополнительных телодвижений не требуется.
Со структорой можно оставить и так, пусть в папке lib\autofac появится version.txt, который можно будет чекать и надобность в componento.db по идее исчезнет.
Н>Со временем выходит новая версия autofac. Разработчик
Н>
Никак не противоречит предлагаемой идеологии, в таске изменится версия на последнюю и autofac будет переустановлен.
Н>При этом проверяются все зависимости, по возможности исключая все конфликтные ситуации, обновляются необходимые сборки и всё.
Н>Насчет тасков ну совершенно непонятно, зачем и почему. А насчет подпапок история отдельная. Сейчас каждый "вендор" творит кто во что горазд. К примеру, архив NUnit'а в качестве корневой папки содержит папку вида "NUnit-x.x.x.x" и если не глядя разархивировать его в lib, то придется править референсы во всех проектах, использующих NUnit. NHibernate же с каждым выпуском архивируется по разному, так что если и его распаковывать "просто в lib", то банально отвалятся референсы на nhibernate.dll. Для того то я и озаботился унифицированой структурой папок и сопоставлениями путей (path-mapping) в манифесте.
Таски для уменьшения зависимости от componento и разбиения его на легко сопровождаемые кирпичики. По сути сам менджер будет лишь рулить файлом билда, а всю работу по установке/апгрейду/удалению выполнит msbuild. Плюс это даст легкость создания новых пакетов.
Н>componento.db -- это не кэш, а база данных установленных компонентов, их зависимостей (а в будущем -- и файлов, из которых состоит компонент). Кэш лежит в %ALLUSERSPROFILE%\octalforty\Componento\componento.cache.db
Я просто где-то в блогах видел папку _componento, это не кеш? База собственно не нужна, все зависимости легко и органично описываются в билдскрипте. Таски по установке и список зависимостей лежат в метаинформации компонента.
Н>Над этим тоже думал, но исключительно в том ключе, что, к примеру,
сделает check out/export исходников из указанного репозитория и сможет собрать проект. Но для этого я всего лишь планировал указывать в манифесте имя скрипта, который надо выполнять по команде build.
Это тоже легко ляжет в предлагаемую концепцию, только строка будет componento build bltoolkit.src, выкачиваем манифест, там урл репозитария и билдскрипт. Урл можно передать свой параметром. Нужно только определиться с соглашениями.
Z>>Например так: Н>
Н>componento init
Н>-- создается componento.proj
Н>componento add nhibernate
Н>-- в componento.proj добавляется таск по установке nh (если вместо add написать install, пакет при этом сразу будет установлен)
Н>componento install (== msbuild componento.proj install, установим все компоненты)
Н>
Н>Вот это интересно, но непонятно, зачем каждый раз при сборке выкачивать откуда-то зависимости, когда можно банально держать их в VCS. Какие плюсы такого подхода?
А зачем каждый раз? Если они установлены это будет всего лишь локальная проверка версий.
Z>>все что происходит открыто и доступно для понимания среднего девелопера, соотвественно легко кастомизируется и внедряется во всякие CI.
Н>Сейчас тоже: всё просто лежит себе в lib.
Да, но сам процесс закрыт. А следовательно плохо расширяем и трудно кастомизируем.
Z>>собрать пакет для нового компонента становится не просто, а очень просто Z>>достаточно легко собрать универсальный пакет для любой версии либы (или скорее реюз кода похожий на порты FreeBSD)
ну тут полет мыслей про то, что билдскрипт для конкретной версии очень легко сделать универсальным.
Пример манифеста в стиле нанта:
<copmonento name="nhibernate"version="2.1"lang="nant">
<include buildfile="${comp.repo}/nhibernate.tasks" /> <!-- nhibernate.tasks будет общий для всех сборок NH, переменную ${comp.repo} задаст componento-->
<property name="nh.version" value="2.1.0.GA" />
<compo-files> <!-- грубый пример, это нужно сделать с параметрами типа хешей или паблик кеев -->
antlr.runtime.dll
Antlr3.Runtime.dll
Castle.Core.dll
Castle.DynamicProxy2.dll
Common.Logging.dll
Iesi.Collections.dll
LinFu.DynamicProxy.dll
log4net.dll
NHibernate.dll
nunit.core.dll
nunit.framework.dll
Remotion.Data.Linq.dll
Remotion.dll
Remotion.Interfaces.dll
Spring.Aop.dll
Spring.Core.dll
</compo-files>
<target name="install">
<call target="nh.download_bin"> <!-- откуда качать определяется в самом таске на основе nh.version -->
<call target="compo.extract">
<call target="nh.compo.params"> <!-- задаем парметры для compo.install на основе списка файлов, платформы и т.п. -->
<call target="compo.install">
</target>
<target name="deinstall">
<call target="nh.compo.params">
<call target="compo.deinstall">
</target>
</copmonento>
Такой манифест легко делается для любой новой версии имеющегося пакета. Для создания манифеста требуется минимум знаний о componento.
Сам componento остается легким и пушистым, с минимумом логики, но расширяемый по самое нехочу. Все что от него требуется, это проверить наличие сборочной платформы (в данном случае nant) и запустить ее. Ну там еще проверки проверки текущей версии и зависимостей.
