it-swarm.com.ru

Должен ли composer.lock поддерживать контроль версий?

Я немного запутался с composer.lock, используемым в приложении с хранилищем.

Я видел, как многие люди говорили, что мы не должны .gitignorecomposer.lock из хранилища.

Если я обновлю свои библиотеки в своей среде разработки, у меня будет новый composer.lock, но я не смогу обновить их в рабочей среде, не так ли?

Не приведет ли это к конфликтам в этом файле?

482
Pierre de LESPINAY

Если вы обновите свои библиотеки, вы также захотите зафиксировать файл блокировки. В основном говорится, что ваш проект привязан к тем конкретным версиям библиотек, которые вы используете.

Если вы фиксируете свои изменения, а кто-то извлекает ваш код и обновляет зависимости, файл блокировки должен быть неизменным. Если он изменен, это означает, что у вас есть новая версия чего-либо.

Наличие этого в хранилище гарантирует, что каждый разработчик использует одинаковые версии.

596
meza

Для приложений/проектов: Определенно да.

документация композитора указывает на это (с акцентом):

Зафиксируйте composer.lock вашего приложения (вместе с composer.json) в системе контроля версий.

Как сказал @meza: Вы должны зафиксировать файл блокировки, чтобы вы и ваши соавторы работали над одним и тем же набором версий и не позволяли вам произносить слова типа «Но это сработало на моем компьютере». ;-)

Для библиотек: Вероятно, нет.

Документация композитора отмечает по этому вопросу:

Примечание. Для библиотек не обязательно фиксировать файл блокировки (...)

И говорится здесь :

Для вашей библиотеки вы можете зафиксировать файл composer.lock, если хотите. Это может помочь вашей команде всегда тестировать на одинаковые версии зависимостей. Однако этот файл блокировки не будет влиять на другие проекты, которые зависят от него. Это влияет только на основной проект.

Для библиотек я согласен с ответом @Josh Johnson.

162
Jeroen Fiege

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

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

Если вас беспокоит изменение ваших зависимостей между обновлениями композитора, то у вас нет уверенности в вашей схеме управления версиями. Версии (1.0, 1.1, 1.2 и т.д.) Должны быть неизменяемыми, и вы должны избегать подстановочных знаков «dev-» и «X. *» вне первоначальной разработки функций.

Фиксация файла блокировки является регрессом для вашей системы управления зависимостями, поскольку версия зависимости теперь вернулась к определению простоты.

Кроме того, ваш проект никогда не нужно перестраивать или пересматривать его зависимости в каждой среде, особенно в prod. Ваш результат (tar, Zip, phar, каталог и т.д.) Должен быть неизменным и распространяться в среде без изменения состояния.

Правка: Я знал, что это не будет популярным ответом, но если вы проголосуете отрицательно, вы будете достаточно любезны, чтобы указать причину в комментариях, которая указывает на недостаток в ответе? Спасибо!

65
Josh Johnson
  1. Вы не должны обновлять свои зависимости напрямую от Production. 
  2. Вы должны контролировать версию своего файла composer.lock.
  3. Вы не должны контролировать версию ваших фактических зависимостей.

1. Вы не должны обновлять свои зависимости непосредственно от Production , потому что вы не знаете, как это повлияет на стабильность вашего кода. Могут быть ошибки, появившиеся в новых зависимостях, это может изменить поведение кода, влияющее на ваши собственные, это может быть несовместимо с другими зависимостями и т.д. Вы должны сделать это в среде разработчика, следуя надлежащему тестированию и регрессионному тестированию и т.д. ,.

2. Вам следует контролировать версию своего файла composer.lock, потому что он хранит информацию о ваших зависимостях и о зависимостях ваших зависимостей, что позволит вам копировать текущее состояние кода. Это важно, потому что все ваши тесты и разработки были выполнены против конкретного кода. Неважно, какая у вас версия кода, похоже на загрузку изменений кода в ваше приложение, а не на их тестирование. Если вы обновляете свои версии зависимостей, это должно быть добровольным действием, и вы должны позаботиться о том, чтобы все работало. Потеря одного или двух часов без возврата к предыдущей версии может стоить вам больших денег.

Один из аргументов, которые вы увидите о том, что вам не нужен composer.lock, заключается в том, что вы можете установить точную версию, которая вам нужна, в вашем файле composer.json, и таким образом, каждый раз, когда кто-то запускает composer install, он установит им тот же код. Это не так, потому что ваши зависимости имеют свои собственные зависимости, и их конфигурация может быть указана в формате, который позволяет обновлять подрывные версии или даже целые версии. 

Это означает, что даже если вы укажете, что вы хотите Laravel 4.1.31 в вашем composer.json, Laravel в его файле composer.json может иметь свои собственные зависимости, необходимые для диспетчера событий Symfony: 2. * , С этим типом конфигурации вы можете получить Laravel 4.1.31 с Symfony event-dispatcher 2.4.1, а кто-то в вашей команде может иметь Laravel 4.1.31 с event-dispatcher 2.6.5, все будет зависит от того, когда вы в последний раз запускали установку композитора.

Таким образом, наличие вашего файла composer.lock в системе версий будет хранить точную версию этих зависимостей, поэтому, когда вы и ваш напарник выполняете установку композитора (именно так вы будете устанавливать свои зависимости на основе на composer.lock) вы оба получите одинаковые версии.

Что делать, если вы хотите обновить? Затем в вашей среде разработки запустите: composer update, это сгенерирует новый файл composer.lock (если есть что-то новое) и после того, как вы его протестируете, а также QA-тестирование и регрессионное тестирование, и прочее. Вы можете отправить его всем остальным, чтобы загрузить новый composer.lock, поскольку его безопасно обновлять.

3. Вы не должны контролировать версию ваших реальных зависимостей , потому что это не имеет смысла. С composer.lock вы можете установить точную версию зависимостей, и вам не нужно их фиксировать. Зачем вам добавлять в репо 10000 файлов зависимостей, если вы не должны их обновлять. Если вам требуется изменить один из этих параметров, вам следует его разветвить и внести в него изменения. И если вас беспокоит необходимость извлекать фактические зависимости каждый раз при сборке или выпуске, у композитора есть различные способы облегчить эту проблему, кеширование, Zip-файлы и т.д.

26
lebobbi

Затем вы фиксируете composer.json в своем проекте, и все остальные в вашей команде могут запустить composer install для установки зависимостей вашего проекта.

Смысл файла блокировки - записать точные версии, которые установлены, чтобы их можно было переустановить. Это означает, что если у вас есть спецификация версии 1. *, и ваш коллега запускает обновление composer, которое устанавливает 1.2.4, а затем фиксирует файл composer.lock, при установке composer вы также получите 1.2.4, даже если 1.3.0 был выпущен. Это гарантирует, что все работающие над проектом имеют одинаковую точную версию.

Это означает, что если что-то было зафиксировано с момента последней установки композитора, то без файла блокировки вы получите новый сторонний код, который будет удален.

Опять же, это проблема, если вас беспокоит взлом вашего кода. И это одна из причин, почему важно думать о том, что Composer сосредоточен вокруг файла composer.lock.

Источник: Композитор: все дело в файле блокировки .


Зафиксируйте composer.lock вашего приложения (вместе с composer.json) в системе контроля версий. Это важно, потому что команда install проверяет, присутствует ли файл блокировки, и, если он есть, загружает указанные там версии (независимо от того, что говорит composer.json). Это означает, что любой, кто настроит проект, загрузит точно такую ​​же версию зависимостей. Ваш CI-сервер, производственные машины, другие разработчики в вашей команде, все и все работают на тех же зависимостях, что снижает вероятность ошибок, затрагивающих только некоторые части развертываний. Даже если вы разрабатываете в одиночку, через шесть месяцев при переустановке проекта вы можете быть уверены, что установленные зависимости все еще работают, даже если с тех пор ваши зависимости выпустили много новых версий.

Источник: Композитор - Основное использование .

6
waanders

Там нет точного ответа на это.

Вообще говоря, composer не должен делать то, для чего предназначена система сборки, и вы не должны помещать composer.lock в VCS. Композитор может быть странным образом задом наперед. Конечные пользователи, а не производители не должны использовать файлы блокировки. Обычно ваша система сборки хранит снимки, многоразовые каталоги и т.д., А не пустой каталог каждый раз. Люди, извлекающие библиотеку из composer, могут захотеть, чтобы эта библиотека использовала блокировку, чтобы были проверены зависимости, загружаемые библиотекой.

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

Принимая это во внимание, я действительно не нахожу файлы блокировки полезными ни для библиотек, ни для ваших собственных рабочих папок. Это единственное использование для меня в моей платформе сборки/тестирования, которая сохраняет любые внешние активы, обновляя их только по запросу, обеспечивая повторяемые сборки для тестирования, сборки и развертывания. Хотя это может быть сохранено в VCS, оно не всегда сохраняется с исходным деревом, деревья сборки будут либо находиться в другом месте структуры VCS, либо управляться другой системой где-то еще. Если он хранится в VCS это спорно или не держать его в том же репо в качестве исходных деревьев, потому что в противном случае каждый тянуть может принести массу строительных активов. Мне очень нравится иметь все вещи в хорошо организованном репо, за исключением производственных/конфиденциальных учетных данных и раздувания.

SVN может делать это лучше, чем git, поскольку он не заставляет вас приобретать весь репозиторий (хотя я подозреваю, что на самом деле он и не нужен строго для git, но поддержка этого ограничена и обычно не используется). Простые репозитории сборки - это просто ветвь оверлея, в которую вы объединяете/экспортируете дерево компоновки. Некоторые люди объединяют внешние ресурсы в своем дереве исходных текстов или разделяют дополнительные, внешние, сборочные и исходные деревья. Обычно он служит двум целям: кеширование сборки и повторяемые сборки, но иногда разделение их хотя бы на некотором уровне также позволяет легко создавать новые/пустые сборки и несколько сборок.

Для этого существует ряд стратегий, и ни одна из них не особенно хорошо работает с сохранением списка источников, если вы не сохраняете внешний источник в дереве исходных текстов.

У них также есть вещи вроде хэшей в файле, как они объединяются, когда два человека обновляют пакеты? Одно это должно заставить вас думать, что, возможно, это неправильно истолковано.

Аргументы, выдвигаемые людьми для блокировки файлов, - это случаи, когда они приняли очень конкретное и ограниченное представление о проблеме. Хотите повторяемые сборки и последовательные сборки? Включите папку поставщика в VCS. Затем вы также ускоряете выборку ресурсов, и вам не нужно зависеть от потенциально поврежденных внешних ресурсов во время сборки. Ни один из создаваемых и развертываемых мной конвейеров не требует внешнего доступа, за исключением случаев, когда это абсолютно необходимо. Если вам нужно обновить внешний ресурс, он будет один и только один раз. То, что пытается достичь композитор, имеет смысл для распределенной системы, за исключением того, что упоминалось ранее, и не имеет смысла, поскольку в результате он может оказаться в аду зависимости библиотек для обновлений библиотек с обычными конфликтами и обновлениями, которые будут работать медленнее, чем самый медленный для обновления пакета.

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

В composer.json вы помещаете нужные вам пакеты и их версии. Вы можете заблокировать версии там. Однако эти пакеты также имеют зависимости с динамическими версиями, которые не будут заблокированы composer.json (хотя я не понимаю, почему вы не можете также поместить их туда самостоятельно, если вы хотите, чтобы они были заблокированы версией), так что кто-то еще запускает установку composer получает что-то другое без блокировки. Вы можете не заботиться об этом, или вы можете заботиться, это зависит. Должны ли вы заботиться? Возможно, хотя бы немного, достаточно, чтобы вы знали об этом в любой ситуации и о потенциальном воздействии, но это также не может быть проблемой, если у вас всегда есть время просто DRY запустить сначала и что-нибудь исправить это было обновлено.

Композитор хлопот пытается избежать, иногда просто не существует, и хлопоты, связанные с файлами блокировки композитора, могут быть существенными. Они не имеют абсолютно никакого права сообщать пользователям, что им следует или не следует делать в отношении сборки по сравнению с исходными ресурсами (будь то объединение отдельных в VCS), поскольку это не их дело, они не являются главой вас или меня. «Композитор говорит» - это не авторитет, они не ваш начальник и не дают никому превосходства в этом вопросе. Только вы знаете свою реальную ситуацию и что лучше для этого. Тем не менее, они могут порекомендовать стандартный курс действий для пользователей, которые не понимают, как все работает, и в этом случае вы можете захотеть следовать этому, но лично я не думаю, что это реальная замена знанию того, как все работает, и способности правильно тренировки ваши требования. В конечном счете, их ответ на этот вопрос является лучшим предположением. Люди, которые делают композитор, не знают, где вы должны хранить свой composer.lock, и не должны. Их единственная обязанность - рассказать вам, что это такое и что он делает. Помимо этого вам нужно решить, что лучше для вас.

Сохранение файла блокировки проблематично для удобства использования, потому что composer очень скрытно использует ли он блокировку или JSON и не всегда хорошо использует оба вместе. Если вы запускаете install, он использует только файл блокировки, он будет выглядеть так, если вы добавите что-то в composer.json, он не будет установлен, потому что он не в вашей блокировке. Не совсем понятно, что на самом деле делают операции и что они делают в отношении файла json/lock и иногда даже не имеют смысла (в справке говорится, что установка требует имя пакета, но при попытке его использовать говорит «нет»). ).

Чтобы обновить блокировку или применить изменения от json, вам нужно использовать update, и вы можете не захотеть обновлять все. Замок имеет приоритет при выборе того, что должно быть установлено. Если есть файл блокировки, это то, что используется. Вы можете ограничить обновление, но система все еще в беспорядке.

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

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

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

Я укажу, что возможность иметь блокировку - это большое удобство, когда у вас есть надежная стратегия сохранения внешних зависимостей, так как она отслеживает информацию, полезную для отслеживания этого (происхождение) и обновления, но если вы этого не делаете тогда это ни здесь, ни там. Это бесполезно, когда его заставляют перерезать горло как обязательную опцию, чтобы оно загрязняло ваши исходные деревья. Это очень распространенная вещь, которую можно найти в унаследованных кодовых базах, где люди внесли множество изменений в composer.json, которые на самом деле не были применены и ломаются, когда люди пытаются использовать composer. Нет composer.lock, нет проблемы с рассинхронизацией.

0
jgmjgm

Если вас беспокоит нарушение кода, вы должны передать composer.lock в вашу систему контроля версий, чтобы все участники проекта использовали одну и ту же версию кода. Без файла блокировки вы будете получать новый сторонний код каждый раз.

Исключением является использование мета-приложений, библиотек, в которых зависимости должны обновляться при установке (например, Zend Framework 2 Skeleton App ). Таким образом, цель состоит в том, чтобы получать последние зависимости каждый раз, когда вы хотите начать разработку.

Источник: Композитор: все дело в файле блокировки

Смотрите также: В чем различия между обновлением композитора и его установкой?

0
kenorb