Я использую композитор для управления своими зависимостями. Эти зависимости расположены в репозитории packagist (общедоступном) и в локальном репозитории композиторов моей компании, который сам получает свои пакеты из экземпляра компании gitlab, где на сервер пакетов отправляются только теги.
Теперь к моей проблеме.
У меня есть пакет, который я назову А. Пакет A имеет зависимость от B. Я редактирую код в B, который я помещаю в ветку git, которая по характеру установки находится только на gitlab, а не на сервере пакетов. B имеет зависимость от C.
Я также должен редактировать личную библиотеку D. D является зависимостью C.
Поэтому я редактирую код в B и D. Мне нужно изменить путь автозагрузки классов psr-4 в D и добавить новое пространство имен в D.
т.е. До:
"autoload": {
"psr-4": {
"hello\\hi": "src/"
}
}
После:
"autoload": {
"psr-4": {
"hello\\hi\\": "src/abc",
"foor\\bar\\": "src/def",
}
}
Как мне заставить автозагрузчик подбирать новые классы, когда для версии D установлен тег (например, ^ 2.0) в C.
Обычно мне требуется версия D для разработчиков в A. Но композитор утверждает, что для пакета C требуется пакет D в версии ^ 2.0.
Мой текущий обходной путь кажется неуклюжим:
Я изменил версию D в C на dev-<branch in gitlab of D>
Я отправил новую ветку в gitlab C.
В B я изменил версию C на dev-<branch in gitlab of C>.
Я отправил новую ветку в gitlab B.
А в a я определяю версию B как dev-<branch in gitlab of B>.
Но ветки gitlab не будут обнаружены, поэтому мне пришлось добавить репозитории gitlab в раздел репозиториев A.
Это должно быть проще, например, принудительно установить пакет независимо от других зависимостей. Это только для целей разработки и тестирования, а не для производства.






Во-первых, тот факт, что вы это делаете, предполагает проблему с вашей архитектурой. Общая библиотека должна иметь четко определенную цель и четко определенный API, который можно тестировать независимо. Таким образом, изменения в пакете D должны быть определены как изменения в этом API и проверены на соответствие этому определению. Возможно, вы захотите провести интеграционное тестирование с его непосредственными зависимостями, но работа с цепочкой из 4 библиотек — плохой знак.
Тем не менее, это реальный мир, так что это, вероятно, не то, что вы можете исправить за ночь.
Псевдоним версии в composer.json позволяет указать, каким ограничениям версии соответствует версия (например, ветка разработки). Это можно указать одним из двух способов (вам не нужны оба):
{"extra":{"branch-alias":{"dev-foo": "2.0.x-dev"}}}.{"require":{"package/D": "dev-foo as 2.0.x-dev"}}В качестве альтернативы, если вы активно разрабатываете обе ветки, а не просто проводите интеграционное тестирование библиотеки, вы можете вообще обойти Composer. Если вы установите для вариант preferred-install значение source, а затем composer install, каждая библиотека будет полным клоном git, и вы сможете переключать ветки и редактировать напрямую. Вы можете использовать composer status, чтобы отслеживать, что вы редактировали вручную. Если вы в конечном итоге сделаете это, определенно стоит подумать о том, как избежать необходимости в этом в будущем.
Спасибо за помощь. Второе предложение работало отлично без каких-либо проблем. Это элегантное решение, которое я искал.
Да, я согласен на 100%, что в этой архитектуре есть серьезная проблема. К сожалению, я не могу изменить его в данный момент. Он был построен задолго до того, как я начал с ним работать, и времени и денег на его очистку не хватает. Я попробую ваше предложение и сообщу как можно скорее. заранее спасибо