OberonCore

Не нравится мне слово от Романа -- "реестр". Попахивает чем-то официально-государственным, чиновниками и мелкомягкими))

Почему бы не быть "каталогу"?
Место конкретного хранения -- не важно. А вот связующее звено -- тут соглашусь с Иваном -- один сервер.
В каком формате качать?... Да не важно. Хотя, удобно будет иметь несколько ссылок на хранилище компонента для скачивания в удобном формате.
В чём Романа поддержу: разрешение зависимостей. Без этого будет зоопарк.
Значит надо начать с аналога рпм, деб, апт. А в структуре каждой подсистемы должен быть предусмотрен файл на подобии String.odc или Compile-List.odc. Скажем, с названием Index.odc (* а в нём -- мыло, автор, лицензия, сайт где обновления лежат (даже несколько ссылок), версия, зависимости, ссылки на компиле-лист, стринг, менюс, и т. д. *)

Требуются уже готовые компоненты или это только для примера? У меня есть парочка недоделанных компонентов. Так-то ими уже можно пользоваться, но я помню, что мне не нравились имена. Да и добавить что-нибудь из функционала, возможно, стоило.

Валерий, вы всегда сможете их обновить позднее. Так что загрузите пока черновой вариант. Это хранилище может быть полезно даже для обмена черновиками.

Для кого-то это слово может вызывать негативные ассоциации. Но не будем сюда примешивать политику.
Можно называть как угодно. Суть от этого не меняется.
Каждый "снимок" кода в отрыве от истории изменений кода менее полезен чем код со всей историей. Поэтому я ратую за интенсивное использование средств контроля версий на любой доступной площадке. Главное, чтобы реестр был "в курсе" дела о том что такой существует. Кому-то нравится Git, кому-то - Subversion. А кто-то вообще выкладывает zip.
Вот, проект npm, к примеру, использует package.json
Пример файла:

Тогда можно было бы даже добавить возможность "вытягивания" кода проекта из простого zip. Хотя я всё же за VCS, так как мотивация изменений фиксируется в истории изменений кода и ясно "откуда ноги растут".

Я за json. Доступный формат, всё ещё доступен для просмотра глазами и редактирования руками.
Средства чтения, записи, парсинга есть практически везде. И по сравнению с XML -- гораздо надёжней, проще, экономичней и быстрей))
Пилю графическую тулзовину для сборки ББ, так отказался от NoSQL-like файла настроек config.db, в пользу config.json))

А кто говорит про "снимки" кода? Код вообще опционален.

Работает ли сайт?

Да, вот он!
https://blackbox.obertone.ru/
Денис, регистрируйся, кстати

Спасибо, я пока не автор, нет причины для регистрации. По самому каталогу уже есть замечания:

1. Слишком мало компонент. http://oberoncore.ru/bbcc/subs/start - здесь гораздо больше, и в других сборниках тоже больше. Если проект с технической точки зрения завершён и претендует на роль CPAN, NPMJS или Quicklisp, то он сможет её выполнять, когда в нём будут все компоненты, которые этого заслуживают. И это будет весьма полезно для привлекательности BBCB как такового.

2. Не вижу руководства. Для примера можно посмотреть на тот же http://oberoncore.ru/bbcc/subs/start
Не иметь руководства - это верный путь к провалу. Человек должен зайти и за 5 минут всё установить и настроить. Это однозначно нужно поправить.

Если же проект с технической точки зрения не завершён, то надо бы его завершить

В любом случае, это так пока, сторонние замечания. Просто я хотел выступить с инициативой по созданию подобного инструмента, а смотрю, он уже в процессе создания. Правда, я пока не готов это финансировать - я всё же пока хочу сконцентрироваться на фичах, а это получилось бы "отапливать вселенную". Думается, люди, более горячо приверженные Оберону, чем я, который пока довольно нейтрален, могли бы внести свою лепту.

Это было так ожидаемо. Умники уровня Хабрахабра почти все такие, видят проблемы, обозначают их неразумным окружающим, а потом сидят и считают, что этого достаточно. Такой герой фильма "Доживём до понедельника", в очочках, с грустью в глазах.

Конечно я мечтаю, чтобы на этом ресурсе собрались все компоненты, вот это даже первый пункт некого перечня задач: http://obertone.ru/wiki/plan
Но! Я что-то не чувствую никакой поддержки сообщества, и поэтому остановился. Есть более важные дела.
Если хочешь, то спонсируй, чтобы каждый автор, который опубликует свой компонент с внятной документацией получил небольшой бонус.
Для развития проекта я сделал форму с пожертвованием, чтобы понимать, что такая система кому-то нужна.
https://blackbox.obertone.ru/about

В плане каталога работай не ради тех, кто уже использует Оберон - они и так всё знают и умеют и у некоторых уже есть подобный свой каталог, свои закладки и т.п. Им это просто не нужно (или они думают, что им это не нужно). А кто-то может и приревновать. Отсутствие поддержки нынешнего сообщества ожидаемо. Да и вообще, продвижение - это статья расхода, от неё не следует ждать быстрой положительной обратной связи.

Целься в новичков, в тех, кто задался вопросом "а что вообще есть в этом BBCB"? Тогда сообщество тех, кто потыкал палочкой, будет расти. И не измеряй интерес пожертвованиями.

Есть ещё такая проблема. Нужно не один раз заполнить компоненты, а отслеживать их развитие. Т.е. нужен способ автоматизированно вытягивать обновления. Тут целый пласт вопросов, некогда на самом деле обсуждать. Может, у тебя это уже есть. Я бы посмотрел, как сделано в ПМ для других языков. Если закачка новых версий не автоматизирована, то поддержка будет становиться всё тяжелее по мере роста.

И мне кажется, что нужно хранить копии всех компонентов у себя на сервере. Quicklisp так делает. Без этого надёжности не будет, т.к. любой сайт может в любой момент исчезнуть. Но похоже, что ты так и делаешь.

Насчёт бонуса - интересный людям бонус я не потяну, а 100 рублей вряд ли кого-то заинтересуют.

Есть прототип менеджера для установки пакетов. Отработал в сборке Red когда-то.
Про то, как отслеживать. Пока я хочу сделать подписку, чтобы люди получали письмо, если какое-то расширение из тех, на которые человек подписался, обновилось.

В общем, если кому-то это интересно, то пусть кинут хоть сотку. Я буду просто знать, что это хоть кому-то нужно Тут мотивация не в деньгах, а в моральной поддержке.

Подписка не особо нужна - или это какой-то люкс, которого в других ПМ нет. А вот хранение "срезов" по датам имеет смысл. Допустим, выпускаешь "релиз" каждый месяц на базе текущих версий библиотек. По идее, версия библиотеки должна быть записана где-то в стандартном месте. Это, конечно, мечты несбыточные. А если такого места нет, то нужно опираться на дату файла или дату последнего коммита.

В npm можно указывать в зависимостях конкретную версию или условие типа "не меньше" на версию библиотеки, или даже диапазон.

Насчёт ожидания обратной связи - ты рано его ждёшь, я уже выше написал. Могу ещё добавить: мир пресыщен технологиями. Нужно выполнить ряд условий, чтобы язык был хоть сколько-то способным бороться за новых пользователей "с улицы". В т.ч. пакетный менеджер - это одно из них.

Поскольку ресурсы ограничены, делай минимум. Никаких там рейтингов и прочего. Но эволюция версия должна быть как-то поддержана, чтобы можно было иметь и 1000 развивающихся компонент, не тратя всё своё время нна обновление. Все решения уже есть, названия я приводил.

Может быть вообще нужно взять да и клонировать тот же npm.

Или вообще прикинуться npm пакетом и использовать имеющуюся npm инфраструктуру. Или bintray, или ещё что.

Денис, спасибо за фидбэк. Надеюсь, что ты разработаешь хоть одной расширение, чтобы было что опубликовать в этом каталоге

Возможность указания диапазона версий порождает проблемы (вроде, NP полные), поэтому лучше без этой фичи

Пока не планирую писать на BBCB, а там посмотрим.