Комментарии 9
Мне казалось Satis — вариант легкого packagist. Просто статическое хранилище репозиториев.
Как вариант — хранить один отдельный репозиторий с vendor + composer.lock, и подтягивать его через git modules
Как вариант — хранить один отдельный репозиторий с vendor + composer.lock, и подтягивать его через git modules
Так они есть лёгкий, и статический. Если заново не билдить, то ни чего и не меняется.
Если я Вас правильно понял, вы предлагаете создать свой пакет со встроенными зависимостями в папку «vendor»? Думаю так не получится, зависимости определяются динамически и каждый пакет будет отдельно тащить пакеты.
Если я Вас правильно понял, вы предлагаете создать свой пакет со встроенными зависимостями в папку «vendor»? Думаю так не получится, зависимости определяются динамически и каждый пакет будет отдельно тащить пакеты.
Нет, я предлагаю хранить в отдельном репозитории зависимости. Например в разработке под ноду вообще считается правильным. Но если мы не хотим засорять историю апдейтами зависимостей — хранить их в отдельном репозитории уже скачанные
Не совсем понимаю в чём проблема. Я у себя в проекты добавляю не только composer.json, но и composer.lock. А при деплое делается install, который полностью происходит из кэша composer. Только для этого должна быть указана версия зависимостей, хотя бы в формате 1.*. А если берётся из какой-то ветки, то тут, конечно будет тормозить.
Проблема с менеджером пакетов заключается в том, что слишком часто приходится устанавливать одни и те же пакеты. Каждая новая установка проекта, это обращение к packagist.org для нахождения источников зависимостей вашего пакета, зависимостей зависимостей и т.д. и дальнейшее скачивание необходимых пакетов. Справедливости ради стоит отметить, что у Composer есть встроенный кэш, но он хранится под ~/.composer/cache, и соответственно индивидуален для каждого пользователя, не говоря уже об отдельных средах для разработчиков, тестеров, QA, продакшн. И везде скачиваются одни и те же пакеты.
rm composer.lock;
В последнем абзаце. Я бы не рекомендовал такое делать. Достаточно кильнують вендоров и кеш компоузера. В файле composer.lock как раз фиксируются версии пакетов, никак не хранятся.
А так же в composer.lock хранятся пути от куда брать исходники, что ни как нас не устраивает при переходе на локальный кэш.
Но вы правы, при условии, что в composer.json прописаны расплывчатые версии, это повлечёт за собой обновление установленных пакетов. Но это уже зависит от вас самих, точнее, ваших настроек.
Но вы правы, при условии, что в composer.json прописаны расплывчатые версии, это повлечёт за собой обновление установленных пакетов. Но это уже зависит от вас самих, точнее, ваших настроек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кэшинг пакетов для Composer