Gemfile.lock dosyasını anlama


181

bundle installKomutu çalıştırdıktan sonra , çalışma dizininde 'Gemfile.lock ' oluşturulur. Bu dosyanın içindeki yönergeler ne anlama geliyor?

Örneğin, aşağıdaki dosyayı alalım:

PATH
  remote: .
  specs:
    gem_one (0.0.1)

GEM
  remote: http://example.org/
  specs:
    gem_two (0.0.2)
    gem_three (0.0.3)
      gem_four (0.0.4)

PLATFORMS
  platform

DEPENDENCIES
  gem_two
  gem_one!

' PATH ', ' GEM ', ' PLATFORMS ' ve ' BAĞIMLILIKLAR ' neyi tanımlar? Hepsi gerekli mi?

' Uzak ' ve ' özellikler ' alt dizinlerini ne içermelidir ?

' DEPENDENCIES ' grubundaki mücevher isminden sonra ünlem işareti ne anlama geliyor?

Yanıtlar:


71

Bu konuda daha fazla bilgiyi bundler web sitesinde bulabilirsiniz (kolaylık olması için aşağıda vurgu yapılmıştır):

Bir süre uygulamanızı geliştirdikten sonra Gemfile ve Gemfile.lock anlık görüntüsü ile birlikte uygulamayı kontrol edin . Şimdi, deponuzda uygulamanın çalıştığından emin olduğunuz son kez kullandığınız tüm mücevherlerin tam sürümlerinin bir kaydı var ...

Bu önemlidir: Gemfile.lock , uygulamanızı hem kendi kodunuzdan hem de her şeyin çalıştığından emin olduğunuz son bildiğiniz üçüncü taraf kodundan oluşan tek bir paket haline getirir. Gemfile'nizde bağımlı olduğunuz üçüncü taraf kodunun tam sürümlerini belirtmek aynı garantiyi sağlamaz, çünkü taşlar genellikle bağımlılıkları için bir dizi sürüm bildirir.


65
Bu, sorularının hiçbirine cevap vermedi, Gemfile.lock formatını soruyor, ancak bu sadece ne yaptığını açıklıyor.
Joshua Cheek

38

ünlem işareti ile ilgili olarak, sadece getirilen taşlar üzerinde olduğunu öğrendim :git, örn.

gem "foo", :git => "git@github.com:company/foo.git"

Vay canına, bunu anlamak için güzel bir çalışma, bunu da merak ettim. Teşekkürler.
JP Silvashy

5
Ayrıca, yerel taşlar pathseçenek aracılığıyla yüklerken de oluşur . Derlenmiş olmayan bir gem yükleme ile ilgisi var sanırım?
Mart'ta zykadelik

Evet, bu bir sebep. Ancak bu bir gem bir ünlem işaretiyle işaretlenmesinin tek nedeni DEĞİLDİR. Şu anda bir kaynak bloğu içinde herhangi bir mücevher bir ünlem işaretiyle işaretlenmiş olarak görüyorum.
Sean Moubry

35

Son birkaç ayı otomatik bağımlılık güncelleme aracı 1 oluştururken Gemfiles ve Gemfile ile uğraşarak geçirdim . Aşağıdakiler kesin olmaktan uzaktır, ancak Gemfile.lock formatını anlamak için iyi bir başlangıç ​​noktasıdır. Bundler'in kilit dosyası ayrıştırıcısının kaynak kodunu da kontrol etmek isteyebilirsiniz .

Bundler 1.x tarafından oluşturulan bir kilit dosyasında aşağıdaki başlıkları bulacaksınız:

GEM (isteğe bağlı ancak çok yaygın)

Bunlar Rubygems sunucusundan kaynaklanan bağımlılıklardır. Bu, Rubygems.org'daki ana Rubygems dizini veya Gemfury ve diğerlerinin kullanabileceği özel bir dizin olabilir. Bu bölümde şunları göreceksiniz:

  • remote: Rubygems dizinlerinin konumunu belirten bir veya daha fazla satır
  • specs: sürüm numaralarıyla birlikte bağımlılıklar listesi ve alt bağımlılıklarla ilgili kısıtlamalar

GIT (isteğe bağlı)

Bunlar belirli bir git uzaktan kumandasından kaynaklanan bağımlılıklardır. Her git uzaktan kumandası için bu bölümlerden farklı bir tane göreceksiniz ve her bölümün içinde şunları göreceksiniz:

  • remote:git uzaktan kumanda. Örneğin,git@github.com:rails/rails
  • revision: Gemfile.lock işleminin gönderme referansı
  • tag: (isteğe bağlı) Gemfile'da belirtilen etiket
  • specs: bu uzaktan kumandada sürüm numarasıyla birlikte bulunan git bağımlılığı ve alt bağımlılıklarla ilgili kısıtlamalar

PATH (isteğe bağlı)

Bunlar pathGemfile'da verilen belirli bir kaynaktan alınan bağımlılıklardır. Her yol bağımlılığı için bu bölümlerden farklı bir tane görürsünüz ve her bölümün içinde şunları görürsünüz:

  • remote:yol. Örneğin,plugins/vendored-dependency
  • specs: bu uzaktan kumandada sürüm numarasıyla birlikte bulunan git bağımlılığı ve alt bağımlılıklarla ilgili kısıtlamalar

PLATFORMLAR

Gemfile.lock'un Ruby platformu oluşturuldu. Gemfile'daki herhangi bir bağımlılık bir platform belirtirse, yalnızca bu dosyada kilit dosyası oluşturulduğunda (örn. Bir yükleme yoluyla) Gemfile.lock içine dahil edilir.

DEPENDENCIES

Burada belirtilen Gemfilesürüm kısıtlamasıyla birlikte belirtilen bağımlılıkların bir listesi .

Ana Rubygems dizini dışında bir kaynakla belirtilen bağımlılıkların (örneğin, git bağımlılıkları, yola dayalı, bağımlılıklar), !bu kaynak 2'ye "sabitlendiği" anlamına gelir (ancak bazen belirlemek için Gemfile'a bakılması gerekir).

YAKUT SÜRÜMÜ (isteğe bağlı)

Bu Gemfile.lock oluşturulduğunda Gemfile içinde belirtilen Ruby sürümü. Bir .ruby_versiondosyada Ruby sürümü belirtilirse, bu bölüm mevcut olmaz (Bundler'ın Gemfile / Gemfile.lock uygulamasının yükleyicinin Ruby sürümüne agnostik olduğunu düşündüğü için).

İLE BİRLİKTE (Bundler> = v1.10.x)

Gemfile.lock oluşturmak için kullanılan Bundler sürümü. Yükleyicilere dosyayı oluşturan sürümden daha eskiyse Bundler sürümlerini güncellemelerini hatırlatmak için kullanılır.

PLUGIN KAYNAĞI (isteğe bağlı ve çok nadir)

Teorik olarak, bir Gemfile Bundler eklentilerini ve daha sonra burada listelenecek olan taşlar 3'ü belirtebilir . Uygulamada, Temmuz 2017 itibariyle mevcut eklentilerin farkında değilim. Bundler'ın bu kısmı hala aktif geliştirme aşamasında!


  1. https://dependabot.com
  2. https://github.com/bundler/bundler/issues/4631
  3. http://andre.arko.net/2012/07/23/towards-a-bundler-plugin-system/

2
en iyi cevap gibi görünüyor
daslicious

9

Bundler, gerekli mücevherleri ve sürümleri izleyip kurarak Ruby projeleri için tutarlı bir ortam sağlayan bir Gem yöneticisidir.

Gemfile ve Gemfile.lock, Bundler gem tarafından verilen birincil ürünlerdir (Bundler'ın kendisi bir mücevherdir).

Gemfile, belirtilen sürüm (ler) ile manuel olarak bahsettiğiniz gem (ler) e proje bağımlılığınızı içerir, ancak bu gem (ler) in girişi, paketleyici tarafından otomatik olarak çözülen diğer gemilere bağlıdır.

Gemfile.lock, Gemfile'daki tüm gem (ler) in tam bir anlık görüntüsünü ve bununla ilişkili bağımlılığı içerir.

Paket yüklemesini ilk kez çağırdığınızda , bu Gemfile.lock dosyasını oluşturur ve bu dosyayı sonraki tüm paket çağrılarında kullanır, bu da tüm bağımlılıkların kurulu olmasını ve bağımlılık yüklemesini atlamanızı sağlar.

Kodunuzu farklı makinelerle paylaştığınızda da aynı şey olur

Gemfile.lock'unuzu Gemfile ile birlikte paylaşırsınız, paket yüklemesini başka bir makinede çalıştırdığınızda Gemfile.lock'unuza başvurur ve bağımlılık çözümleme adımını atlar, bunun yerine, kullandığınız tüm aynı mücevherleri birden fazla makinede tutarlılığı koruyan orijinal makine

Neden birden fazla makinede tutarlılığı korumamız gerekiyor?

  • Farklı makinelerde farklı sürümler çalıştırmak, bozuk kodlara neden olabilir

  • Uygulamanızın 1.5.3 sürümünü kullandığını ve 14 ay önce
    sorunsuz çalıştığını ve
    Gemfile.lock olmadan farklı bir makineye yüklemeye çalıştığınızı varsayalım. Şimdi 1.5.8 sürümünü alıyorsunuz. Belki bazı mücevherlerin en son sürümüyle kırılmıştır ve uygulamanız
    başarısız olacaktır . Tutarlılığı korumak son derece önemlidir (tercih edilen
    uygulama).

Gemfile.lock içindeki gem (ler) i paket güncellemesini kullanarak güncellemek de mümkündür .

Bu, muhafazakar güncelleme kavramına dayanmaktadır


8

Bana PATH birinci nesil bağımlılıkları doğrudan gemspec'inizden listelerken, GEM ikinci nesil bağımlılıkları (yani bağımlılıklarınızın neye bağlı olduğunu) ve Gemfile'nizi listeliyor gibi görünüyor. PATH :: remote, PATH :: .spec'e ait olanı bulmak için geçerli dizindeki yerel bir gemspec'e dayanmasıdır, oysa GEM :: remote, GEM'e ait olanı bulmak rubygems.orgiçin gitmesi gereken yer olduğu için spec.

Rails eklentisinde bir PATH bölümü görürsünüz, ancak Rails uygulamasında görmezsiniz. Uygulamanın bir gemspec dosyası olmadığından, PATH'ye koymak için hiçbir şey olmazdı.

BAĞIMLILIKLAR'a gelince, gembundler.com şunları ifade eder:

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

Tarafından üretilen Gemfile rails plugin new my_pluginbenzer bir şey söylüyor:

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

Bunun anlamı,

s.add_development_dependency "july" # (1)

ve

s.add_dependency "july" # (2)

(1) bir geliştirme ortamında yalnızca Gemfile.lock (ve dolayısıyla uygulamada) "temmuz" u içerecektir. Yani koştuğunuz zaman bundle install, "temmuz" u sadece PATH altında değil, aynı zamanda BAĞIMLILIK altında da değil, sadece geliştirme aşamasında göreceksiniz. Üretimde hiç olmayacak. Bununla birlikte, (2) 'yi kullandığınızda, "temmuz" u BAĞIMLILIKLAR'da değil, sadece PATH'de görürsünüz, ancak bundle installbir üretim ortamından (yani, bağımlılığınızı içeren başka bir mücevherde), sadece gelişme.

Bunlar sadece benim gözlemlerim ve bunun neden böyle olduğunu tam olarak açıklayamıyorum ama daha fazla yorum bekliyoruz.


3

Biçimde konuşan net bir belge yok gibi görünüyor Gemfile.lock. Belki de Gemfile.locksadece paket tarafından dahili olarak kullanıldığı için.

Ancak, Gemfile.lockbir anlık görüntüsü olduğundan Gemfile, tüm bilgilerinin Gemfile(veya belirtilmemişse varsayılan değerden) gelmesi gerektiği anlamına gelir Gemfile.

Için GEM, doğrudan veya dolaylı olarak tanıttığınız tüm bağımlılıkları listeler Gemfile. remotealtında GEMnerede tarafından belirtilen taşlar, almak söyler kaynağında yer Gemfile.

Bir mücevher alınamayacak değilse remote, PATHonu bulmak için konum söyler. PATHbireyin bilgi geliyor yolun içinde Gemfilebir bağımlılık bildirirken.

Ve PLATFORMarasındadır burada .

Çünkü DEPENDENCIES, paket tarafından çözülen bağımlılıkların anlık görüntüsü.


0

'DEPENDECIES' grubundaki mücevher isminden sonra ünlem işareti ne anlama geliyor?

Ünlem işareti, taş " https://rubygems.org " dışında bir kaynak kullanılarak kurulduğunda görünür .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.