Чи повинен прихильник composer.lock контролювати версії?


529

Я трохи плутаюсь із composer.lockвикористовуваним у програмі зі сховищем.

Я бачив, як багато людей казали, що ми не повинні .gitignore composer.lockзі сховища.

Якщо я оновлю свої бібліотеки в середовищі розробників, у мене з’являться нові, composer.lockале я не зможу оновити їх у виробництво, чи не так?

Чи не створить конфлікт цей файл?


1
Цей зв'язок тепер мертвий @markus
Kyrre

Відповіді:


673

Якщо ви оновлюєте свої вкладки, ви також хочете скористатися файлом блокування. В основному йдеться про те, що ваш проект заблокований для тих конкретних версій, які ви використовуєте.

Якщо ви здійснюєте свої зміни, а хтось витягує ваш код і оновлює залежності, файл блокування має бути немодифікованим. Якщо він модифікований, це означає, що у вас є нова версія чогось.

Наявність його у сховищі запевняє, що кожен розробник використовує однакові версії.


5
Добре, але уявіть, якщо я оновлюю бібліотеки з виробничого середовища, composer.lock буде перезаписаний, тож наступний витяг із виробництва попросить мене об'єднати цей файл ...
Pierre de LESPINAY

7
Якщо composer.lock видозмінюється, вам потрібно повернути модифікації назад у сховище. Якщо ви хочете прив’язати програмне забезпечення до певних версій бібліотек, то зробіть це явно в конфігурації. Таким чином замок ніколи не зміниться. Розгляньте файл блокування як індикатор проблеми управління залежністю, яку потрібно вирішити так чи інакше.
меза

361
У виробництві ви не повинні оновлювати свої залежності, ви повинні запустити, composer installякий буде читати з файлу блокування, і нічого не змінювати.
Seldaek

112
"У виробництві не слід оновлювати свої залежності", слід писати у всіх шапках
Хоакін Л. Роблесс

75
@ JoaquínL.Роботи у ВИРОБНИЦТВІ ВИ ВАМ НЕ БУДІТЬ ОНОВЛЮВАТИ ВАШІ ЗАВДАННЯ! :)
Елін Й.

201

Для заявок / проектів : Безперечно, так.

Про це (з акцентом) документація композитора зазначає:

Введіть composer.lock програми (разом із composer.json) у контроль версій.

Як сказав @meza: Ви повинні скопіювати файл блокування, щоб ви та ваші співробітники працювали над тим самим набором версій і не дозволяли вам висловлюватися на зразок "Але це працювало на моєму комп'ютері". ;-)

Для бібліотек : Напевно, ні.

Документація композитора відзначає це питання:

Примітка. Для бібліотек не обов'язково рекомендується вводити файл блокування (...)

І тут говориться :

Якщо ви хочете, для своєї бібліотеки ви можете скопіювати файл composer.lock. Це може допомогти вашій команді завжди перевіряти однакові версії залежності. Однак цей файл блокування не матиме жодного впливу на інші проекти, які від нього залежать. Це впливає лише на основний проект.

Щодо бібліотек, я погоджуюся з відповіддю @Josh Johnson.


Навіщо ставитися до проектів на роботі інакше, ніж "бібліотеки"?
Джош Джонсон

4
Можливо, вживання слова «колеги» тут бентежить, я змінив його на співпрацівників. Основна відмінність - "основний проект" проти бібліотеки, в якому основний проект складається з однієї або декількох бібліотек та коду для їх інтеграції. Під час запуску композитора з головного проекту він не використовує файл composer.lock бібліотеки, тому він встановлює свої залежності в останній версії. Я думаю, це має бути подібним під час тестування вашої бібліотеки.
Jeroen Fiege

2
Зв'язок файлу блокування з бібліотекою - це, мабуть, хороша річ - документи з файлами блоку, які версії залежностей були встановлені під час запуску тестового набору. Це особливо важливо в команді, особливо в умовах постійної інтеграції.
mindplay.dk

Нетривіальні конфлікти можуть виникнути при реінтеграції в гілки магістралі 2, в яких обоє мають нові пакети, встановлені через композитора.
Відбулося

2
@tonix, я можу відповісти на це деяким авторитетом! Причина, що я не здійснюю composer.lock для моїх бібліотек, полягає в тому, що мій CI будує майстра щовечора незалежно від того. Це гарантує, що якщо будь-яка із залежностей бібліотеки має проблеми з оновленням у користувача бібліотеки, то CI не вдасться. Добре працює!
Теодор Р. Сміт

86

Після того як я це зробив обома способами для кількох проектів, моя позиція полягає в тому, що composer.lockне слід брати участь у проекті.

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

Якщо ви стурбовані тим, що ваші залежності змінюються між оновленнями композиторів, тоді ви не довіряєте своїй схемі версій. Версії (1.0, 1.1, 1.2 тощо) повинні бути незмінними, і вам слід уникати символів "dev-" та "X. *" за межами початкової розробки функції.

Здійснення файлу блокування є регресією для вашої системи управління залежністю, оскільки версія залежності тепер повертається до неявного визначення.

Крім того, ваш проект ніколи не повинен відбудовуватися або переробити його залежність у кожному середовищі, особливо у виробництві. Ваш товар (tar, zip, phar, каталог тощо) повинен бути незмінним та просуватися через середовище без змін.


19
Домовились. Я вважаю, що має більше сенсу вказувати версії залежностей, composer.jsonде потрібніші версії більш чітко вказані. Але якщо ви не встановите конкретні версії, краще скористатися composer.lock. Це заплутано, якщо вказані в версії composer.jsonвідрізняються від встановлених відповідно до версії a composer.lock. Також це залежить від програми (власного або загального випуску) та її циклу розробників. Звичайно, документи-композитори жирним шрифтом говорять : "Зверніть composer.lock програми (разом із composer.json) у контроль версій" . Вибирай розумно =)
Квінн Комендант,

10
Після довгого пошуку душі я вирішив, що в цьому пункті, композитори-документи помиляються :) У мене є правило, що я не додаю створений матеріал до VCS; Я дозволяю процесу збирання впоратися з цим.
Джош Джонсон

10
Чи не код, створений за допомогою ваших біомеханічних натискачів клавіш, "створений матеріал"? Я не впевнений, що це солідний критерій, на якому базується політика. =)
Квінн Комендант

5
@borfast Я знаю, що я трохи запізнююся на розмову, тому ви, можливо, бачили це до цього моменту, але ви можете вказати хеш у composer.json. У requireрозділі ви можете поставити: "repo": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e". Це буде 1) перейти до гілки, 2) замовити хеш, 3) якщо хеш не буде знайдено на гілці, однак він перевірить голову зазначеної гілки (майстер у цьому випадку).
CEPA

5
@CEPA - Це дивно. Я б очікував, що це не вдасться, якби хеш не вдалося знайти. Здається небезпечним.
Натан JB

31
  1. Не слід оновлювати свої залежності безпосередньо від виробництва.
  2. Вам слід керувати версією файлу composer.lock .
  3. Не слід версії контролювати фактичні залежності.

1. Не слід оновлювати свої залежності безпосередньо від виробництва , оскільки ви не знаєте, як це вплине на стабільність вашого коду. Можуть бути введені помилки з новими залежностями, це може змінити спосіб поведінки коду, що впливає на вашу власну, він може бути несумісний з іншими залежностями і т. Д. Ви повинні робити це в середовищі розробників, дотримуючись належного тестування якості та регресії, тощо. .

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-диспетчером подій 2.4.1, а хтось інший у вашій команді міг би мати Laravel 4.1.31 з подій-диспетчером 2.6.5, все залежатиме від того, коли був останній раз, коли ви запускали інсталятор композитора.

Отже, ваш файл composer.lock у версійній системі зберігатиме точну версію цієї підзалежності, тож, коли ви та ваш товариш по команді зробите композицію, встановіть (саме так ви встановите свої залежності на основі композитора. замок ) ви обидва отримаєте однакові версії.

Що робити, якщо ви хочете оновити? Потім у вашому середовищі composer updateрозробки :, це створить новий файл composer.lock (якщо є щось нове), і після того, як ви його протестуєте, і тест якості та регресія перевіряйте його та інше. Ви можете підштовхнути його до всіх інших, щоб завантажити новий composer.lock , оскільки його безпечно оновити.

3. Не слід версії контролювати фактичні залежності , оскільки це не має сенсу. За допомогою composer.lock ви можете встановити точну версію залежностей, і вам не потрібно їх робити. Чому б ви додали до репо 10000 файлів залежностей, коли ви не повинні їх оновлювати. Якщо вам потрібно змінити щось із цього, слід роздрібнити його та внести зміни. І якщо ви турбуєтесь про те, що вам доведеться добирати фактичні залежності кожного разу при складанні чи випуску, композитор має різні способи полегшити цю проблему, кешувати, поштові файли тощо.


1
Дякую, я думаю, що ця відповідь пояснює, чому ви повинні версія composer.lock, а якщо ні, то які наслідки є і чи можете ви з ними жити.
Хосе Лозано Ернандес

8

Потім ви покладете composer.jsonна свій проект, і всі інші у вашій команді можуть запустити інсталяцію композитора для встановлення залежностей вашого проекту.

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

Це означає, що якщо щось було вчинено з моменту останнього встановлення композитора, то, без блокування файлу, ви отримаєте новий сторонній код, який буде знятий .

Знову ж таки, це проблема, якщо ви стурбовані порушенням вашого коду. І це одна з причин, чому важливо думати про композитор як про центр composer.lock.

Джерело: Композитор: Все про файл блокування .


Введіть composer.lock програми (разом із composer.json) у контроль версій. Це важливо, оскільки команда install перевіряє наявність файлу блокування, і якщо він є, він завантажує вказані там версії (незалежно від того, що пише composer.json). Це означає, що кожен, хто налаштовує проект, завантажить точно таку ж версію залежності. Ваш сервер CI, виробничі машини, інші розробники у вашій команді, все і всі працюють на одних і тих же залежностях, що зменшує потенціал помилок, що впливають лише на деякі частини розгортань. Навіть якщо ви розвиваєтеся самостійно, через півроку при перевстановці проекту ви можете бути впевнені, що встановлені залежності все ще працюють, навіть якщо з тих пір ваші залежності випустили багато нових версій.

Джерело: Композитор - Основне використання .


1

Якщо ви стурбовані порушенням вашого коду, вам слід скоїти це composer.lock системою контролю версій, щоб усі ваші співробітники проекту використовували одну і ту ж версію коду. Без файлу блокування ви отримуватимете новий код сторонніх розробників кожного разу.

Виняток становить, коли ви використовуєте мета-додатки, бібліотеки, де залежність має бути оновлена ​​при встановленні (як-от додаток Zend Framework 2 Skeleton ). Отже, мета полягає в тому, щоб щоразу, коли ви хочете почати розвиватись, захоплювати останні залежності.

Джерело: Композитор: Все про файл блокування

Дивіться також: Які відмінності між оновленням композитора та встановленням композитора?


1

Точної відповіді на це немає.

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

З іншого боку, що значно збільшує тягар управління версіями, де ви майже напевно хочете, щоб кілька версій кожної бібліотеки, оскільки залежності будуть суворо заблоковані. Якщо кожна бібліотека, ймовірно, має дещо іншу версію, тоді вам потрібна підтримка декількох бібліотечних версій, і ви також можете швидко побачити потрібний розмір залежностей, тому радимо зберігати її на аркуші.

Враховуючи це на борту, я дійсно не знаходжу файли блокування, щоб бути корисними ні бібліотекам, ні вашим власним робочим каталогам. Для мене це лише користь у моїй платформі зборки / тестування, яка зберігає будь-які зовнішні активи, лише оновлюючи їх за потреби, надаючи повторювані збірки для тестування, збирання та розгортання. Хоча це може бути збережено у VCS, воно не завжди зберігається з деревом-джерелом, але дерева збірки будуть або в іншому місці структури VCS, або керуватися іншою системою десь в іншому місці. Якщо він зберігається у VCS, дискусійним є питання про те, чи потрібно тримати його в тому ж репо, що і вихідні дерева, тому що в іншому випадку кожен потяг може принести масу активів нарощування. Мені дуже подобається, щоб все було в добре організованому репо, за винятком виробничих / чутливих даних та можливостей.

SVN може зробити це краще, ніж git, оскільки він не змушує вас придбати всю репо-репортаж (хоча я підозрюю, що насправді для git теж не потрібна, але підтримка цього обмежена, і вона не використовується зазвичай). Прості репозити збірки, як правило, є лише накладеною гілкою, в яку ви зливаєте / експортуєте дерево збірки. Деякі люди поєднують ресурси, використовувані у своєму вихідному дереві, або відокремлюють далі, зовнішні, будівельні та вихідні дерева. Зазвичай він служить двом цілям, кешування збірок і повторюваних збірок, але іноді тримаючи його окремо хоча б на якомусь рівні, також дозволяється створювати свіжі / порожні збірки та безліч збірок.

Для цього існує низка стратегій, і жодна з них не справляється із збереженням списку джерел, якщо ви не зберігаєте зовнішнє джерело у своєму дереві джерел.

У них також є такі речі, як хеші у файлі, як це злитися, коли двоє людей оновлюють пакети? Це одне повинно змусити вас думати, можливо, це неправильно пояснено.

Аргументи, які люди висувають для файлів блокування, - це випадки, коли вони сприйняли дуже специфічний та обмежуючий погляд на проблему. Хочете повторюваних і послідовних збірок? Включіть папку постачальника у VCS. Тоді ви також прискорите отримання активів, а також не потрібно залежати від потенційно порушених зовнішніх ресурсів під час збирання. Жоден із створених мною трубопроводів побудови та розгортання не вимагає зовнішнього доступу, якщо це абсолютно не потрібно. Якщо вам доведеться оновити зовнішній ресурс, це один раз і лише один раз. Те, що композитор намагається досягти, має сенс для розподіленої системи, за винятком випадків, про які говорилося раніше, немає сенсу, оскільки це закінчиться пеклами залежностей бібліотеки для оновлень бібліотек із загальними сутичками та оновленнями, які проходять так само повільно, як найповільніші оновлення пакету.

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

У composer.json ви ставите потрібні вам пакунки та їх версії. Ви можете заблокувати версії там. Однак ці пакети також мають залежність від динамічних версій, які не будуть заблоковані composer.json (хоча я не розумію, чому ви також не могли їх розмістити там, якщо ви хочете, щоб вони були заблоковані), щоб хтось інший, хто працює із композитором, встановив виходить щось інше без блокування. Вас може не хвилювати з цього приводу або, можливо, все одно, це залежить. Ви повинні турбуватися? Напевно, хоч трохи, щоб переконатися, що ви знаєте про це в будь-якій ситуації та потенційному впливі, але це може бути не проблемою, якщо ви завжди матимете час просто СУХИЙ запустити першим і виправити все, що оновилося.

Композитор клопоту намагається уникати іноді просто не там, і клопоту з файлами блокування композитора можуть зробити важливі. Вони абсолютно не мають права говорити користувачам, що вони повинні чи не повинні робити у відношенні побудови проти вихідних активів (чи приєднатись до окремих в VCS), оскільки це не їхня справа, вони не є начальником вас чи мене. "Композитор каже:" це не влада, вони не є вашим старшим офіцером, і вони нікому не дають переваги з цього приводу. Тільки ви знаєте своє реальне становище і що для цього найкраще. Однак вони можуть порадити звичайний спосіб дій користувачам, які не розуміють, як все працює, і в такому випадку ви можете дотримуватися цього, але особисто я не думаю, що " справжній замінник того, щоб знати, як все працює, і вміти правильно тренувати ваші вимоги. Зрештою, їх відповідь на це питання - найкраща здогадка. Люди, які складають композитора, не знають, де слід тримати ваш composer.lock, а також не слід. Їх єдина відповідальність - сказати вам, що це таке і що робить. Поза цим вам потрібно вирішити, що краще для вас.

Збереження файлу блокування є проблематичним для зручності використання, оскільки композитор дуже секретно стосується того, використовує він замок або JSON і не завжди добре використовувати обидва разом. Якщо ви запустите встановити, він використовує лише файл блокування, він з’явиться, тому якщо ви додасте щось до composer.json, він не буде встановлений, оскільки він не знаходиться у вашому блокуванні. Зовсім не інтуїтивно зрозуміло, що насправді виконують операції та що вони роблять щодо файлу json / lock, а іноді, здається, навіть не має сенсу (довідка каже, що встановлення займає назву пакета, але при спробі його використання говорить, що ні ).

Щоб оновити блокування або в основному застосувати зміни з json, вам доведеться використовувати оновлення, і ви, можливо, не захочете все оновлювати. Замок має перевагу у виборі того, що слід встановити. Якщо є файл блокування, це те, що використовується. Можна дещо обмежити оновлення, але система все ще просто безлад.

Оновлення займає вік, концерти оперативної пам’яті. Я також підозрюю, що якщо ви підбираєте проект, який не чіпали на деякий час, що він виглядав із версій, які у нього з'явилися, яких з часом буде більше, і він, мабуть, не робить цього ефективно, що просто задушить його.

Вони дуже примхливі, якщо мова йде про секретні складені команди, яких ви не могли розраховувати на складання. За замовчуванням команда видалення композитора відображається на картах для оновлення композитора, наприклад, видалення композитора.

Питання, яке вам справді потрібно задати, полягає не в тому, чи слід тримати замок у вашому вихідному дереві, або, чи потрібно продовжувати його десь якимось чином чи ні, а краще запитати, що він насправді робить, тоді ви можете вирішити для себе коли вам потрібно це наполегливо і де.

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


0

Так, очевидно.

Це тому, що локально встановлений композитор надасть першу перевагу файлу composer.lock над composer.json.

Якщо файл блокування недоступний у vcs, композитор вкаже на файл composer.json для встановлення останніх залежностей або версій.

Файл composer.lock підтримує залежність більш глибоко, тобто вказує на фактичну прихильність версії пакету, яку ми включаємо в наше програмне забезпечення, отже, це один з найважливіших файлів, який обробляє залежність більш тонко.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.