composer

Общий формат указания версии пакета такой:

[constraint][@stability flag]

или по-русски:

[ограничение-версии][@флаг_стабильности]

таким образом:

"require": {
    "foo/package": "@dev"
}

-- это вообще что угодно, а вот:

"require": {
    "foo/package": "dev-main"
}

-- вроде как завязка на конкретную версию,

Чтобы работь с версиями на основе гит-а пригодиться

composer require "some/backend-pack @dev"

Суть вопроса

Нужен способ сделать следующее:

• Установить внутри контейнера (по сценарию в Dockerfile) пакет, который ходится в приватном репозитории (на гитхабе или битбакете)

Т.е. перед этим у вас уже должен быть:

Например так:

В этом уроке мы начнем разбираться с работой менеджера зависимостей Composer в части того, что он предоставляет собственную стандартизированную автозагрузку классов для проекта (без учета того, что он еще и управляет зависимостями, с которыми мы разберемся в следующих уроках)

Итак, кратко о том что такое зависимости и пакеты. Прочитали?
Мы уже стакивались с ними в разделе по SimpleMVC.
Делать этот урок мы будем на примере решения задачи

Задача

У нас есть какой-то код (пусть он лежит в файле index.php):

В этом разделе мы потренируемся использовать менеджер зависимостей composer, с которым ранее уже сталкивались в разделе про SimpleMVC.

Выполним следующие задания, чтобы лучше понять как работает управление зависимостями:

1. Урок #1 composer и Автозагрузка -- загружаем внутренние классы нашего проекта

Do you trust .... to execute code and wish to enable it now? (writes "allow-plugins" to composer.json

Чтобы понять почему при require (или указании диапазона возможных версий) устанавливается не так версия, что вы ожидаете, просто попробуйте установить конкретную версию пакета (ту что вы хотите, в сообщении будет расшифровано почему выбрана другая версия).

Для проверки, после запуска скрипта, в котором не получается загрузить файл целиком гляньте сгенерированный композером файл:

vendor/composer/autoload_files.php

-- там лежит то, что он грузил ориентируясь на composer.json

Ситуация

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

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

Проблема

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

Возможное решение

Решением может быть следующее: