Как получить точную версию включенных пакетов в моем личном репозитории

Сейчас я экспериментирую с Satis. Я хотел бы иметь возможность где-то получить точную версию моих личных пакетов, поэтому все, что обычно находится в файле composer.lock. Я всегда коммит composer.lock через Git.

Но если я правильно понимаю, Satis в своих packages.json всегда включает только обязательные части, то есть разделы из моего composer.json и, следовательно, только диапазоны версий.

Есть ли способ настроить Satis так, чтобы composer.locks также сохранялись, или как мне получить точный снимок моих пакетов?

+++ Пример +++

Хорошо, я попытаюсь объяснить немного больше.

Допустим, у меня есть пакет my/package. Здесь я добавляю несколько файлов, в том числе composer.json, в котором я определяю, что symfony/console должен быть установлен в версии выше или равной 4. Теперь я выполняю установку composer, и Symfony устанавливается в версии 4.4. Я фиксирую все файлы, включая composer.lock, и создаю релиз 1.0.

Теперь я еду в Сатис. Здесь я добавляю my/package и соответствующий URL репозитория для my/package в satis.json и обновляю его. Satis правильно проверяет мой пакет, и в packages.json или, точнее, в all*.json мой пакет указан с версией 1.0. Пока все в порядке.

Но если я сейчас взгляну на метаданные, которые Satis хранит для моего пакета во всех *.json, я увижу здесь практически указанные мной требования, т.е. что symfony/console должен быть установлен в версии выше или равной 4. Итак, Satis делает снимок composer.json и явно игнорирует composer.lock. Так что у меня нет шансов увидеть, что мой релиз 1.0 работает точно с версией 4.4 Symfony, в то время как, например, релиз 1.1 работает с symfony/console 4.5. Но эта информация мне интересна.


person altralaser    schedule 29.07.2020    source источник
comment
Где вы хотите хранить что-либо? Composer только читает пакеты из Satis и ничего там не хранит   -  person Nico Haase    schedule 29.07.2020
comment
т.е. Я вызываю example.com/packages.json и анализирую его.   -  person altralaser    schedule 29.07.2020
comment
Звучит нормально - а в чем проблема с разбором этого файла пакета?   -  person Nico Haase    schedule 30.07.2020
comment
Проблема в том, что нет номеров версий. Похоже, Satis сохраняет только требования, а не реально установленные версии, а хотелось бы их знать.   -  person altralaser    schedule 30.07.2020
comment
Сатис ничего не устанавливает. Не могли бы вы пояснить, что точно вы ищете? Какие данные вы хотите получить и в чем проблема прочитать эти данные из composer.lock?   -  person Nico Haase    schedule 30.07.2020
comment
Я изменил свой пост.   -  person altralaser    schedule 02.08.2020
comment
Если релиз 1.1 вашего пакета работает с symfony/console 4.5 и не работает с symfony/console 4.4, вы должны обновить ограничение в composer.json вашего пакета. Это точка ограничения - он предоставляет диапазон версий для зависимостей. Чем шире диапазон, тем меньше вероятность возникновения конфликтов зависимостей. Использование точной версии из composer.lock в основном гарантирует конфликты, потому что каждый пакет может иметь некоторые незначительные отличия.   -  person rob006    schedule 02.08.2020


Ответы (2)


При установке пакета Composer на лету пересчитывает все зависимости. Это основано на composer.json файлах вашего приложения и composer.json файлах всех зависимостей.

composer.lock не должен быть частью какого-либо пакета, и он не принимается во внимание при установке пакета.

person Nico Haase    schedule 02.08.2020
comment
Вы можете иметь composer.lock в своем пакете (и это часто полезно), просто он не будет использоваться, когда вы устанавливаете этот пакет в качестве зависимости. - person rob006; 02.08.2020
comment
@ rob006, можете ли вы поделиться несколькими примерами, где это может быть полезно? Я только что просмотрел некоторые пакеты (Symfony, Laravel, Guzzle, Google API Client SDK, PHPUnit), и ни в одном из этих репозиториев не указан файл блокировки. Просматривая список популярных пакетов, ребята из Doctrine были первыми, у кого я смог найти файл блокировки. - person Nico Haase; 02.08.2020
comment
@ rob006, чтобы поместить это в отдельный вопрос, я открыл stackoverflow.com/questions/63214966 - и я был бы очень рад слышать от вас :) - person Nico Haase; 02.08.2020
comment
Это ускоряет установку (например, для тестов CI) и обеспечивает стабильное состояние зависимостей, поэтому, если ваш PR не проходит тесты, это ошибка PR, а не какой-то несвязанный сбой BC в одной из зависимостей (вам все еще нужен какой-то процесс для обновления этой блокировки регулярно). Но это в основном полезно для приватных пакетов с известной средой — Symfony должна поддерживать несколько версий PHP, поэтому они не могут использовать одну блокировку, поэтому она не так популярна в проектах ОС. - person rob006; 02.08.2020
comment
Как говорит Роб, имеет смысл сохранить стабильную версию. Когда вы запускаете Composer Install, вы всегда получаете самые последние версии и можете внести критические изменения в свой проект или, по крайней мере, непроверенные стенды. Так что это на самом деле очень распространенный способ. - person altralaser; 03.08.2020
comment
@altralaser, можете ли вы поделиться примерами этого распространенного способа? Как я уже писал, из списка некоторых очень популярных пакетов только Doctrine использует этот. И обычно вы не хотите использовать стабильные версии при разработке библиотеки, которая не используется в сочетании со статическим набором других пакетов. - person Nico Haase; 03.08.2020
comment
Если вы хотите использовать статический набор зависимостей в своей библиотеке, вы можете использовать очень точные номера версий в своей composer.json, но это затруднит использование вашей библиотеки другими пользователями. - person Nico Haase; 03.08.2020
comment
Извините, но я не знаю, какие еще примеры привести... - person altralaser; 03.08.2020
comment
Приложение: Я полагаю, вы никогда не создавали частные пакеты, которые затем можно было бы интегрировать в более крупные приложения. Релизная версия здесь очень важна, чтобы избежать ошибок в работающих системах. И, конечно же, это обычный способ проверки composer.lock в приватных пакетах. Вы не найдете этого в Doctrine & Co., это точно. Или займитесь развертываниями. Здесь вы хотите развернуть версию, которую вы тестировали, поэтому вы в основном выполняете установку композитора только с существующим composer.lock. - person altralaser; 04.08.2020
comment
Я думаю, вы не знаете, над какими проектами я работал, даже если это не поможет решить вашу проблему. Можете ли вы пояснить, почему должно быть различие между частными и общедоступными пакетами? Что заставляет вас думать, что Composer знает об этой разнице и обрабатывает их по-разному? - person Nico Haase; 04.08.2020
comment
Итак, можете ли вы привести пример, когда при установке пакета используется composer.lock, присутствующий в репозитории этого пакета, и не пересчитываются зависимости, необходимые для установки этого пакета? - person Nico Haase; 04.08.2020
comment
Я думаю, что объяснил это подробно. Что еще я могу сказать ... - person altralaser; 04.08.2020

Итак, я создал обходной путь. Все это не совсем идеально, так как время выполнения для больших репозиториев относительно велико, из-за чего мне приходится запускать его как cron один раз в день. Но это работает нормально.

  • Я создал новую консольную команду Satis.
  • Эта команда использует класс PackageSelection для определения всех существующих пакетов.
  • Я перебираю список пакетов и ищу пути и имена к файлам dist.
  • Я извлекаю ZIP-файлы в память и ищу composer.lock. Если он есть, я анализирую его и читаю точные номера версий зависимых пакетов.
  • Я суммирую информацию в отдельном файле JSON и храню ее параллельно с packages.json в htdocs. Оттуда я могу вызвать его и интегрировать в свое собственное приложение или обработать дальше.
person altralaser    schedule 04.08.2020