Нет конечно :)

хуже вот виртуальных пространств не будет )

а чего так?

А зачем нужен еще один менеджер пакетов. Нужно понять почему они не взлетают и устранить недостаток. Кто-то однажды сорвет куш

Они не нужны. Давай вспомним, зачем пакетные менеджеры: зависимости тягать. И почему-то на уровне ОС - работает. Другое дело - если в стандартные механизмы ОС не уметь.

Применительно к FP: линкер заберёт библиотеку откуда скажешь.

из более-менее реальных попыток только Delphinus на ум приходит. Но там автор, похоже, не озаботился посмотреть на уже существующие реализации. Либа идентифицируется GUID'ом, например.
Про недавнюю реализацию автором Finalbuilder'a я уже писал.
Из объективных сложностей тот факт, что хочется именно компонентами управлять, а это не предусмотрено самим механизмом компонент. Хотя с перезапуском IDE возможно разный набор компонент загружать

чем они тебе так не угодили? может ты их как менеджер пакетов пытался использовать? так они не про это. менеджер пакетов - pip

нет, просто концепция не нравится )

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

зависит кто что делает, конечно. может быть полезен

читаю очередную статью go против rust:https://habr.com/ru/post/487116/

"Реализация службы на Go не соответствовала всем требованиям. Большую часть времени она работала быстро, но каждые несколько минут начинались сильные задержки, заметные для пользователей. После изучения ситуации мы определили, что задержки объясняются ключевыми особенностями Go: его моделью памяти и сборщиком мусора (GC)."

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

а чтобы "взлетело" на мой взгляд необходимо:
1. поддержка сообщества, чтобы разорвать порочный круг - если в нем не будет библиотек, никто не будет пользоваться. если никто не пользуется - зачем туда библиотеку отправлять?
2. вменяемый дизайн и архитектура - чтобы было удобно пользоваться, без лишних заморочек, зависимостей от IDE и т.п.
3. независимость от платформы, компилятора, IDE - куда приятнее, когда либа становится доступна через менеджер сразу всем. Да и нет причин привязываться к чему-либо. В конце концов дело менеджера зависимостей - найти либу и положить куда скажут

Допилил два компонента для Vcl, кому интересно. Progressbar и Trackbar

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

«В Lazarus есть хорошая модель подключаемых пакетов, где необходимые пакеты указаны в файле проекта. Для пакетов задается условие, диапазон версий» Да, мало кто использует. Но для меня открытие, что в Дельфи такого механизма нет.... ( Странно

Я как-то пробовал писать свой менеджер пакетов, потом забил. Чуть позже появился OPM (Online Packages Manager) для Lazarus. Если кому интересно - можете его дорабатывать.

Да, у OPM есть будущее ИМХО