Відповіді:
Тут Gemfileви вказуєте, які дорогоцінні камені ви хочете використовувати, і дозволяє вам вказати версії.
У цьому Gemfile.lockфайлі Bundler записує точні версії, які були встановлені. Таким чином, коли таку ж бібліотеку / проект завантажено на іншу машину, запущений bundle installбуде дивитись на Gemfile.lockта встановлювати такі самі версії, а не просто використовувати Gemfileта встановлювати останні версії. (Запуск різних версій на різних машинах може призвести до зламаних тестів тощо). Вам ніколи не слід було б безпосередньо редагувати файл блокування.
Ознайомтеся з ціллю та обгрунтуванням постачальника , зокрема, Перевірка вашого коду в розділі «Управління версіями».
Зазвичай ми записуємо залежності в Gemfile так:
gem "nokogiri", "~> 1.4.4"
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'uglifier', '>= 1.2.3'
..Тут ви в основному говорите: " Я хочу nokogiri до тих пір, поки він перевищує версію 1.4.4 " і т. Д. Тепер припустимо, що я створив свій Gemfile 8 місяців тому і успішно налаштував свій додаток з цією вимогою. 8 місяців тому версія nokogiri склала 1.4.4 . Мої програми на рейках працювали ідеально без проблем із цією версією.
Тепер подумайте, що я намагаюся будувати з тим самим Gemfile. Але якщо ми подивимось на версії nokogiri, то побачимо, що поточна стабільна версія змінилася на 1.4.9 . Це означає, що якщо ми спробуємо створити, bundler встановить версію 1.4.9 nokogiri (припустимо, у нас її немає Gemfile.lock).
Як ви бачите, якщо у вас немає таких, Gemfile.lockзапустіть:
bundle installто використовувані в даний час дорогоцінні камені можуть бути різними в будь-який час . Ваша програма використовує версію 1.4.4 і вона працює 8 місяців тому без будь - яких проблем, але якщо ви намагаєтеся побудувати його прямо зараз ви отримаєте версію 1.4.9 . Можливо, це порушено з останньою версією nokogiri, дивовижна функція, яку ви використовували з 1.4.4 , недоступна та ін.
Для запобігання такої проблеми Gemfile.lockвикористовується. Вписані Gemfile.lockлише точні версії , і таким чином будуть встановлені лише вони. Це означає, що якщо ви поширюєте свою програму за допомогою Gemfile.lock, на кожній машині буде встановлено однакові дорогоцінні камені, і найголовніше, щоб усі вони отримували однакову версію . Це дасть вам стабільний і загальний стек розгортання.
Він створюється автоматично з першим:
bundle installкомандування. Після цього щоразу, коли ви запустите bundle install, пакет спочатку шукатиме Gemfile.lockі встановлюватиме вказані там дорогоцінні камені. Це звичка розповсюджувати цей файл серед своїх проектів, щоб забезпечити стабільність та стабільність.
Якщо ви задоволені останньою версією своїх програм, ніж ви можете оновити Gemfile.lock. Просто відобразіть ваші зміни до Gemfile. Це означає змінити залежності на нові точні версії в Gemfile. Після цього запустіть:
bundle installЦе дозволить вам оновити Gemfile.lockвашу найновішу версію програм.
nokogiri ~> 1.4.4не дозволила 1.5.3б встановити; макс дозволено було б 1.4.xде x>=4(для nokogiri це було б 1.4.7). У ~>оператор означає тільки остання цифра в використану дорогоцінний камінь може бути «більше» даної версії. Наприклад, foo ~> a.b.c.dозначає, що будь-яка версія файлу fooє прекрасною, поки вона все ще abc {щось} де {щось} >=d. Дивіться також пов'язане запитання
gem "nokogiri", "~> 1.4.4"в gemfile. Чому постачальник не міг просто використовувати цю версію? Це тому, що він призначений навмисно встановити останні версії самоцвіту за замовчуванням?
~> 1.4.4еквівалентно >= 1.4.4 and < 1.5. Див. Bundler.io/v1.5/gemfile.html . Для точної версії просто використовуйте gem 'foo', '1.4.4'.
bundle installперевірятиме, Gemfileнавіть якщо є Gemfile.lockі застосовуватимуться нові обмеження Gemfile.lock?
Gemfile.lock
Під час запуску встановлення пакета Bundler збереже повні імена та версії всіх використовуваних вами дорогоцінних каменів (включаючи залежності дорогоцінних каменів, зазначених у Gemfile (5)) у файл, який називається Gemfile.lock.
Bundler використовує цей файл у всіх наступних викликах для встановлення пакету, що гарантує, що ви завжди використовуєте той самий точний код, навіть якщо ваша програма переміщується на машинах.
Через те, як працює роздільна здатність залежності, навіть, здавалося б, невелика зміна (наприклад, оновлення точкового звільнення залежності дорогоцінного каміння у вашому Gemfile (5)) може призвести до кардинально різних дорогоцінних каменів, необхідних для задоволення всіх залежностей.
Як результат, Ви ДОЛЖНЕ перевірити свій Gemfile.lock на контроль версій. Якщо цього не зробити, кожна машина, яка перевіряє ваш сховище (включаючи ваш виробничий сервер), знову усуне всі залежності, що призведе до використання різних версій стороннього коду, якщо будь-який із дорогоцінних каменів у Gemfile (5) чи будь-який їх залежності були оновлені.
Gemfile.lockвключає «відкриті» версії в деяких випадках (наприклад,rails (4.0.0)вимагаєbundler (>= 1.3.0, < 2.0)), що спричиняє проблеми. Будь-яка ідея, як уникнути цих "відкритих" залежностей?