OberonCore

БлэкБоксу не хватает менеджера управления подсистемами с автоматическим скачиванием с репозитория, наподобие apt-get, gem и прочих. Только для GUI, соответственно.

Имеется ввиду что-то наподобие Monticello?

Как NetBeans, к примеру:

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

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

Да, автоматика заборет сложность "установки", но станет причиной неконтролируемого роста сложности зависимостей между компонентами.

Это решение явно не оптимальное, поэтому говорить о его глобальной необходимости --- не верно.

P.S. Эта тема, по-моему, уже поднималась. Может кто помнит? Объединить, или хотя бы ссылками связать...

Почему рост станет неконтроллируем? Ведь выбор за пользователем, он и решает в итоге.

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

Вы не поняли. Пользователь компонента ничего не решает. Решает разработчик. А если последний будет знать, что "я могу заюзать любой компонент и мне за это ничего не будет (автоматика все зависимости сама втянет)", то тогда уж точно (почти) никто не будет думать ни количестве зависимостей ни об объёме...

По-моему, основная фишка "apt-get, gem.." прежде всего в автоматическом разрешении зависимостей. А не в просмотре списка файлов компонента. Или я не прав?

1) Компоненты распространяются в архивах. Сделать удалённый простмотр содержимого архива.
2) За "версии" отвечает среда выполнения.

Т.е. ради 1-2 копировать apt-get --- я пока и не понимаю, зачем..

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

Меня в основном напрягает много тыкания руками из-за многих зависимостей во время распаковки (последний раз --- ставил Casket поглядеть латех-формулы). А Вы, Роман, из-за каких сложностей проблему подняли?

Насчёт необходимости копировать 1:1 и вправду нужно подумать. Зато список доступных для компонент был бы удобен: просмотрел зависимости, выбрал нужное, нажал на "установить". Хоп! Установлено! Разве не заманчиво?

Поднял вопрос из-за лени выполнения рутинных операций по установке компонент. Люблю когда просто.

Ещё для регуляции версий нужно иметь в каждом компоненте информацию о ней. А на сей момент это пока не используется.

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

Немного доделать SetupList (модуль для скачивания и установки подсистем), сделать актуальный репозиторий (работа, последнее время, активно начата на OberonCore), осталась система контроля версий, фингерпринт в помощь и опять же таблица с фингерпринтами в репозитории.

Кто ж не любит когда просто? С этим спору нет.

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

Поясните, пожалуйста, что значит "регуляция версий" (и для чего она нужна).

BB1.6 скачивает пакеты для BB1.6, а BB1.5 - для BB1.5. И т.п. но на деле будет несколько сложнее, поскольку добавление каждого нового элемента в или метода в объект ведет к его несовместимости, что жестко пресекается самим BB при попытке использования таких компонентов, поэтому нужна Супер-Таблица, которая хранит сочетающиеся между собой фингерпринты модулей и предлагает скачать именно работоспособный пакет для вашей версии, или вычисляет, какие компоненты надо обновить, чтобы требуемый пакет пользователем заработал. Также надо по желанию загружать только коды или коды и тексты модулей (так сказать режим разработчика, как в Ubuntu).

Для автоматизации этой рутины по сути не хватает команды загрузки файла. Точнее, её надо доделать:

Для начала --- вроде всё
1) Автор компонета может приложить своими руками сделанный тул-документ с командами для скачки, распаквоки, компиляции и пр. всех зависимых компонентов. (Это хороший стопор для наличия у компонента n^m неявных зависимостей, невменяемого объёма.)
2) Списки компонентов можно перечислить в одном документе. С кратким описанием и командами скачки/.../открытия quick-start. Пример этого, кажется, как раз в SetupList.

ИМХО: на данный момент ничем не обоснованное усложнение. И уж точно --- сразу хвататься ещё и за него --- не стоит.

Скорее, опять, --- первоочередное желание сделать как у всех...

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

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

Спасибо за упоминание о SetupList. Посмотрю.

Насчёт "далеко вперёд" --- согласен.

1) Главный момент --- недопустить некорректной работы компонента в окружении, которое не соответствует его требованиям, --- гарантирует (обязана) среда выполнения.
2) Второй --- избавление пользователя от качания компонента, который не заработает.
Учитывая текущие реалии:
- автор знает о зависимостях публикуемого им компонента
- знает где взять необходимые компоненты
По сути, для любого компонента из коллекции Цинна или оберонкоре, это верно. Если компонент опубликован, то его зависимости разрешимы. Т.е. проблема проверки зависимостей сейчас не стоит.