Ну ок, они (кто?) копируют в OPM некую "стабильную" версию

из репозитория гита/свн? или не так? в чём сложность сохранить привязку к tag ?

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

не спорю, это удобно, но, как тут уже было сказано, версии пакетов в OPM могут протухать и не соответствовать текущим в VCS

Могут. Тут больше вина автора компонента или другие причины. Но в целом как правило, к примеру, с rx компонентами, которые часто не собираются, даже в стабильных своих версиях. В OPM всегда собирается. И по другим компонентам. Дальше. В новых версиях OPM автоматически следит за новыми релизами в GitGub и других репозитариях. Сам пока не проверял работоспособность, но уже есть и давно относительно

это всё гут, но зачем убирать контрольную инфу VCS ?

Это метка, которая в старых VCS юзалась что ли? Или что? Честно говоря не особо понял и проблему или вопрос

для этого есть гит, есть make

не понял, 2 копии пакета иметь?

нет. я к тому что это решается без opm, а нормальным опенсорсным способом. opm потому что так дельфисты привыкли))

а, я думал это мне ответ ) согласен

Где-то make, где-то want, где-то вообще gradle, а где-то .bat с самописными инсталляторами. И к этому ещё свои зависимости тоже могут быть. Запускаешь make а он тупо не находит какую-то команду. Или другую библиотеку. И в каждой либе свои заморочки с установкой тоже. Понятно, что если это твои любимые либы, то они у тебя стоят давно без всяких пакетов, а как их собирать и разбирать ты знаешь не хуже автора. Но вот тут недавно про skia говорили, например. Вот допустим, захотел человек потыкать delphi-skia 2 часа в воскресенье перед сном, а ему для этого нужно сначала найти где брать саму skia,где под неё брать компилятор, где брать сишные либы, куда их класть, как сишный тулчейн настраивать... Если он к утру понедельника хотя бы собрать библиотеку сможет - то уже молодец. Хотя каждый отдельный шаг для авторов этих библиотек не просто лёгкий, а самоочевидный.

make тут сгоряча упомянули

автор зависимости заботливо описал всё в ридми же. а если не описал, наврятли такая зависимость в опм попадет

Тут ровно то же, что с дистрами Если кто-то заморочился в орм/delphinus/getit опакетить - то будет. А вот как раз первоначальному автору может быть недосуг. У него эта библиотека тупо всегда есть на компе, потому что он её в других проектах пользует. И в прописывать скачивание и сборку её в makefile не будет, потому что не нужно и компьютеров без этой идеально собранной либы в его мире просто не существует

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

Так актуальное состояние это не прописывать ничего. Потому что у автора на компе они всегда есть и всегда актуальны. Зачем же лишнее писать.

Для чего есть гит?

помимо прочих достоинств, в том числе и для легкого распространения исходников

Конечно. Легкое распространение исходников. А причем тут OPM? Как они мешают друг другу?

тут 2 подхода 1 - почитать ридми и доустановить зависимости 2 - посмотреть видосик и прокликать как там обьяснили вот опм больше про второй вариант)) имхо

Ну это твое ИМХО. Я видео вообще не смотрю. Пакетный менеджер это унификация и упрощения работы с компонентами в проекте, легкая установка прямо с IDE, в независимости на каком хостинге кода он хостится или не на хостинге кода вообще. Не важно. OPM подключает любые пакеты

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

в общем, понятно... когда надо быстро что-то попробовать, "ковырнуть" - OPM удобен но если нужна отладка пакета и возможная его правка - то без VCS будет гемор