Считаю, что менеджер компонентов нужно рассматривать только в рамках экосистемы для хранилища компонентов.
Сегодня самый крупный ресурс с опубликованными компонентами для КП - это
Component Pascal Collection (CPC).
Для того, чтобы опубликовать новую версию компонента, каждый раз нужно обращаться к Хельмуту. Это не удобно, да и создаёт на него лишнюю нагрузку.
Сегодня самой популярными площадками для публикации являются GitHub, Bitbucket, GitLab (помимо SourceForge, CodePlex и прочих).
Преимущества таких хранилищ ясны:
- код компонентов хранится на открытых хранилищах и доступен всем в любое время (если доступ не заблокирован)
- не зависит от графика работы кого-либо из разработчиков
- есть управление версиями кода компонентов
- есть экспорт в архивы zip, tar.gz
- любой может создать ответвление от опубликованного компонента согласно своему видению
- при этом видно кто какой вклад внёс
- можно участвовать в разработке, предлагая свои изменения и управлять ими
- код можно просматривать онлайн
- есть сопутствующие вспомогательные средства: Wiki, bug tracking, графики ...
Многие современные менеджеры пакетов сегодня поддерживают скачивание прямиком с GitHub. Можно даже выбрать, использовать ли определённые выпуски, ветви разработки или даже самый свежий код.
Для управления версиями компонентов в корне проекта обычно вставляют специальный файл, который менеджер пакетов считывает и знает откуда брать (скачивать по протоколам HTTPs/Git/SVN/...) компоненты и каких версий, включая разрешение зависимостей.
То есть менеджер пакетов обязан знать по адресу какого ресурса (реестра) нужно обращаться для того, чтобы скачать тот или иной компонент. Ведь откуда в реестре может появиться сведения о том что кто-либо опубликовал новую версию компонента? В случае же компонентов КП никаких таких реестров компонентов пока не имеется. Чтобы другие разработчики узнали о новом компоненте, нужно, чтобы существовал такой реестр, который позволил бы разработчику
самостоятельно, заполнив опросный лист (название компонента и т.д.), занести информацию в реестр.
Ранее я писал (2013-й год):
http://forum.oberoncore.ru/viewtopic.php?f=127&t=4407&hilit=sourceforge&start=0#p81258Цитата:
Если есть заинтересованные в ББ лица, то я предложил бы SourceForge.net в качестве платформы для:
хранилища для бинарных версий под разные ОС (включая разные их версии)
хранилища бинарных версий и исходных кодов компонентов пользователей, чтобы их можно было скачивать прямо из ББ парой кликов из менеджера пакетов
списка рассылки (по общим вопросам использования и прочим)
отслеживания исправлений по найденным ошибкам
координации действий, дальнейшего развития
Конечно, если продолжать вести общение по-русски (что многим гораздо удобнее), то нерусскоговорящие заходить туда, скорее всего, не станут и тогда ни о какой централизации Оберон-сообщества речи быть не может.
Можно или же взять за основу OberonRevival, попросив доступа у Димыча или же зарегистрировать другой (опять же, дублирование).
Когда речь идёт об исходных кодах, то есть некоторые нюансы:
исходные коды компонентов могут постоянно находиться в процессе разработки и поэтому напрягает каждый раз обращаться к кому-то с целью обновить их.
могут быть разветвления от одного источника разработки.
авторы компонента могут прекратить их разработку, поэтому надо дать возможность другим подхватить разработку.
По-моему, SourceForge такой гибкости работы с исходными кодами не даёт, в отличие от GitHub, BitBucket и подобных.
Пожалуй, нет смысла ограничивать разработчика в выборе подходящей для него платформы для проекта (типа SourceForge).
Таким образом, код должен находиться на любой площадке, а реестр должен иметь сведения о компонентах, находящихся на них.
В качестве примера реестра компонентов предлагаю взглянуть на
http://rubygems.org/ (язык Ruby)