Использование нескольких хабов для "локальных" изменений пакетов.

[Ndochp]

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

Предполагается следующий сценарий:
-1. Поднимается локальный хаб
0. Дорабатывается типовая библиотека, для того чтобы она выглядела предпочтительной ей поднимается версия, например дописывая 9 к номеру основной слева

1. библиотека публикуется на локальном хабе
2. По команде opm update --all OPM получает списки версий с локального и центрального хабов, для отсутствующих на локальном хабе должны подтянуться пакеты из центрального, для пакетов, что есть на локальном взять с него (из за номера версии)

Честно говоря, может и работает уже. Пока споткнулся на этапе разворачивания локального хаба и публикации в него. Андрей Овсянкин спросил сюда сценарий написать, а не в проект хаба, пусть будет.

[EvilBeaver]

Как вариант - не поднимать версии, а просто прописывать "свой" хаб первее внешнего. Останется неоднозначность на случай если ты написал opm instal gitsync, у тебя локальный форк, но "свой" хаб почему-то упал. Тогда скачается внешний, недоработанный гитсинк, а ты об этом не узнаешь.

Кажется, что надежнее переназывать пакеты, а не дорабатывать с тем же именем+большая версия

[CrazyHackGUT]

Кажется, что надежнее переназывать пакеты, а не дорабатывать с тем же именем+большая версия

А если этот доработанный пакет висит в зависимостях у другого?

[EvilBeaver]

Поменять зависимость у другого. Не надо пытаться хакнуть систему версий. Поменяв пакет на свой ты теперь зависишь от другого пакета. Не от старого. Любые попытки подсунуть новый, как старый - это хаки, которые могут работать, а могут и нет