Ответ 1
Основная проблема здесь заключается в использовании ветвей (dev-master) вместо отмеченных версий. Использование ветвей, скорее всего, закончится проблемами. Я смотрю вопросы Composer на Stackoverflow, и каждый раз, когда кто-то сообщает о проблемах с пакетами, они используют ветки развития и "минимальную стабильность: dev" в 99% случаев.
Что происходит? Я должен предположить, что вы хотите установить эти пакеты в первый раз. Поэтому Composer не устанавливает, а обновляет пакеты. В противном случае рабочий набор версий, способных выполнять все требования к версии, был бы записан в composer.lock
.
Итак, вот ситуация зависимости: два пакета зависят от третьего пакета, но эти два требуют несовместимых версий.
Вы можете это исправить? В локальном файле composer.json
есть только один инструмент, который сможет разрешить установку третьего пакета: установка его с помощью встроенной псевдонимы версии.
"require": {
"anahkiasen/former": "dev-master",
"vespakoen/menu": "dev-master",
"anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}
Установив ветку dev-master и объявив ее равной версии 1.1.2, Composer может разрешить зависимости обоих пакетов.
Проблема заключается в том, что он не сработает в тот момент, когда у вас есть три пакета в зависимости от четвертого - в трех разных версиях.
Правильная вещь для каждой ветки развития должна включать объявление ветки-алиаса в THEIR composer.json
, что позволит Composer обнаружить, что ветвь dev-master фактически эквивалентна версии 1.1.x, что могло бы помочь здесь (но нет, если какой-либо пакет явно требует определенного номера версии - 1.1.x не является 1.1.2). Добавление псевдонимов ветки по-прежнему является хорошей вещью и должно быть сделано. Если сопровождающий хочет избежать постоянного обслуживания этого псевдонимов с жесткой кодировкой в composer.json
, они могут альтернативно разработать эту версию в ветке, которая имеет версию .x в своем имени (то есть "v1.1.x" или "1.1. x" будет обнаружен Composer, чтобы содержать указанную версию в стабильности разработки).
Обратите внимание, что проблема, которую я описал в последнем абзаце, заключается в том, что для пакетов явно требуется данный номер версии. При таком подходе, если вам нужен такой пакет, вы не можете использовать другую версию этого зависимого пакета самостоятельно или в другом пакете. Хотя могут быть случаи, когда требуется только одна версия, лучшим решением является необходимость в диапазонах версий.
Мое личное предпочтение заключается в использовании оператора каретки для версий более 1.0: ^1.1.7
потребует 1.1.7 в качестве минимальной версии, но не будет обновляться до версии 2.0.0, которая считается несовместимой с изменениями. Если пакет тщательно помечен новой версией в соответствии с семантическим версированием, это работает как шарм. Вы никогда не будете удивлены несовместимыми изменениями (если, конечно, человеческая природа не вмешивается, но вы должны обнаружить эту ошибку и отбросить обновление, если ваше программное обеспечение ломается).
Для версий ниже 1.0 обратите внимание, что оператор каретки работает не так, как оператор тильды - обратитесь к руководству для более подробной информации. Я предпочитаю тильду для пакетов под моим контролем, которые были помечены 0.x, чтобы получить "совместимые" обновления функций, даже если семантическое управление версиями позволяет несовместимые обновления в диапазоне 0.x.
Но даже без семантического управления версиями каждая маленькая неточность в номере версии помогает, например, определение 1.1.*
(предположительно, будет обновляться во всех предстоящих выпусках исправлений) или >=1.1.2,<1.2.5
.
Худшие вещи требуют "dev-master". Хотя это действительно очень неточно (он будет разрешен для любой возможной фиксации в ветке, в зависимости от времени обновления), проблема в том, что вы не можете вернуться к предыдущей версии "dev-master", если не знаете точно, какое commit ID, и добавьте это требование в composer.json
. Но тогда вы находитесь в точно такой же ситуации, как и выше, для чего требуется точная версия (тег git - это только именованный псевдоним для идентификатора commit).