Memahami file Gemfile.lock

Setelah menjalankan bundle installperintah, 'Gemfile.lock ' dibuat di direktori kerja. Apa arti arahan di dalam file itu?

Sebagai contoh, mari kita ambil file berikut:

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!

Apa yang digambarkan oleh ' PATH ', ' GEM ', ' PLATFORMS ' dan ' DEPENDENSI '? Apakah mereka semua diharuskan?

Apa yang harus mengandung subdirektori ' jarak jauh ' dan ' spesifikasi '?

Apa arti tanda seru setelah nama permata di grup ' DEPENDENSI '?

Anda dapat menemukan lebih banyak tentang itu di situs web bundler (penekanan ditambahkan di bawah untuk kenyamanan Anda):

Setelah mengembangkan aplikasi Anda untuk sementara waktu, periksa aplikasi bersama dengan snapshot Gemfile dan Gemfile.lock . Sekarang, repositori Anda memiliki catatan tentang versi persis semua permata yang Anda gunakan terakhir kali Anda tahu pasti bahwa aplikasi itu berfungsi ...

Ini penting: Gemfile.lock membuat aplikasi Anda satu paket dari kode Anda sendiri dan kode pihak ketiga yang dijalankannya terakhir kali Anda tahu pasti semuanya bekerja. Menentukan versi pasti dari kode pihak ketiga yang Anda andalkan di Gemfile Anda tidak akan memberikan jaminan yang sama, karena permata biasanya mendeklarasikan serangkaian versi untuk dependensi mereka.

sehubungan dengan tanda seru saya baru tahu itu pada permata yang diambil melalui :git, misalnya

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

Saya telah menghabiskan beberapa bulan terakhir bermain-main dengan Gemfiles dan Gemfile. Saya sering mengunci kunci saat membangun alat pembaruan ketergantungan otomatis ¹ . Di bawah ini masih jauh dari definitif, tetapi ini adalah titik awal yang baik untuk memahami format Gemfile.lock. Anda mungkin juga ingin memeriksa kode sumber untuk parser lockfile Bundler .

Anda akan menemukan judul berikut di file kunci yang dihasilkan oleh Bundler 1.x:

GEM (opsional tetapi sangat umum)

Ini adalah dependensi yang bersumber dari server Rubygems. Itu mungkin indeks Rubygems utama, di Rubygems.org, atau indeks kustom, seperti yang tersedia dari Gemfury dan lainnya. Dalam bagian ini Anda akan melihat:

• remote: satu atau lebih baris yang menentukan lokasi indeks Rubygems
• specs: daftar dependensi, dengan nomor versinya, dan batasan pada setiap subdependensi

GIT (opsional)

Ini adalah dependensi yang bersumber dari git remote yang diberikan. Anda akan melihat bagian yang berbeda ini untuk setiap remote git, dan di dalam setiap bagian Anda akan melihat:

• remote:remote git. Misalnya,git@github.com:rails/rails
• revision: referensi komit yang Gemfile.lock dikunci
• tag: (opsional) tag yang ditentukan dalam Gemfile
• specs: dependensi git ditemukan pada remote ini, dengan nomor versinya, dan batasan pada setiap subdependensi

PATH (opsional)

Ini adalah dependensi yang bersumber dari yang diberikan path, disediakan di Gemfile. Anda akan melihat bagian yang berbeda dari ini untuk setiap ketergantungan jalur, dan di dalam setiap bagian Anda akan melihat:

• remote:jalan. Misalnya,plugins/vendored-dependency
• specs: dependensi git ditemukan pada remote ini, dengan nomor versinya, dan batasan pada setiap subdependensi

PLATFORMS

Platform Ruby tempat Gemfile.lock dibuat. Jika ada dependensi dalam Gemfile menentukan platform maka mereka hanya akan dimasukkan dalam Gemfile.lock ketika lockfile dihasilkan pada platform itu (misalnya, melalui instalasi).

DEPENDENSI

Daftar dependensi yang ditentukan dalam Gemfile, bersama dengan batasan versi yang ditentukan di sana.

Dependensi yang ditentukan dengan sumber selain dari indeks Rubygems utama (misalnya, dependensi git, berbasis path, dependensi) memiliki !yang berarti "disematkan" ke sumber ² (walaupun seseorang kadang-kadang harus mencari di Gemfile untuk menentukannya).

VERSI KARET (opsional)

Versi Ruby ditentukan dalam Gemfile, ketika Gemfile.lock ini dibuat. Jika versi Ruby ditentukan dalam .ruby_versionfile sebagai gantinya bagian ini tidak akan hadir (karena Bundler akan mempertimbangkan Gemfile / Gemfile.lock agnostik ke versi Ruby pemasang).

DILAKUKAN DENGAN (Bundler> = v1.10.x)

Versi Bundler digunakan untuk membuat Gemfile.lock. Digunakan untuk mengingatkan penginstal untuk memperbarui versi Bundler mereka, jika lebih lama dari versi yang membuat file.

SUMBER PLUGIN (opsional dan sangat jarang)

Secara teori, Gemfile dapat menentukan plugin Bundler, serta permata ³ , yang kemudian akan terdaftar di sini. Dalam praktiknya, saya tidak mengetahui adanya plugin yang tersedia, pada Juli 2017. Bagian dari Bundler ini masih dalam pengembangan aktif!

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/

Bundler adalah manajer Gem yang menyediakan lingkungan yang konsisten untuk proyek-proyek Ruby dengan melacak dan menginstal permata dan versi yang tepat yang diperlukan.

Gemfile dan Gemfile.lock adalah produk utama yang diberikan oleh permata Bundler (Bundler sendiri adalah permata).

Gemfile berisi ketergantungan proyek Anda pada permata, yang Anda sebutkan secara manual dengan versi yang ditentukan, tetapi permata tersebut bergantung pada permata lain yang diselesaikan oleh bundler secara otomatis.

Gemfile.lock berisi snapshot lengkap dari semua permata di Gemfile bersama dengan ketergantungan yang terkait di sana.

Ketika Anda pertama kali memanggil bundle install , itu akan membuat Gemfile.lock ini dan menggunakan file ini di semua panggilan berikutnya untuk bundel install, yang memastikan bahwa Anda memiliki semua dependensi yang diinstal dan akan melewati instalasi dependensi.

Hal yang sama terjadi ketika Anda membagikan kode Anda dengan mesin yang berbeda

Anda membagikan Gemfile Anda. Buka bersama Gemfile, ketika Anda menjalankan bundel install di komputer lain, itu akan merujuk ke Gemfile Anda. Buka dan lewati langkah resolusi dependensi, alih-alih itu akan menginstal semua permata dependen yang sama yang Anda gunakan pada mesin asli, yang mempertahankan konsistensi di beberapa mesin

Mengapa kita perlu menjaga konsistensi di beberapa mesin?

• Menjalankan versi berbeda pada mesin yang berbeda dapat menyebabkan kode rusak

• Misalkan, aplikasi Anda menggunakan versi 1.5.3 dan berfungsi 14 bulan yang lalu
  tanpa masalah, dan Anda mencoba menginstal pada mesin yang berbeda
  tanpa Gemfile. Buka sekarang Anda mendapatkan versi 1.5.8. Mungkin rusak dengan permata versi terbaru dan aplikasi Anda akan
  gagal. Mempertahankan konsistensi adalah yang paling penting (
  praktik yang disukai ).

Dimungkinkan juga untuk memperbarui permata di Gemfile.lock dengan menggunakan pembaruan bundel .

Ini didasarkan pada konsep pembaruan konservatif

Sepertinya saya seperti PATH mendaftar dependensi generasi pertama langsung dari gemspec Anda, sedangkan GEM mencantumkan dependensi generasi kedua (yaitu ketergantungan pada siapa Anda) dan yang berasal dari Gemfile Anda. PATH :: remote adalah .karena ini bergantung pada gemspec lokal di direktori saat ini untuk mengetahui apa yang termasuk dalam PATH :: spec, sedangkan GEM :: remote adalah rubygems.org, karena di situlah ia harus pergi untuk mencari tahu apa yang termasuk dalam GEM :: spek.

Di plugin Rails, Anda akan melihat bagian PATH, tetapi tidak di aplikasi Rails. Karena aplikasi tidak memiliki file gemspec, tidak akan ada yang dimasukkan ke dalam PATH.

Adapun DEPENDENSI, gembundler.com menyatakan:

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

Gemfile dihasilkan oleh rails plugin new my_plugin mengatakan sesuatu yang serupa:

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

Ini artinya perbedaan antara keduanya

s.add_development_dependency "july" # (1)

dan

s.add_dependency "july" # (2)

adalah bahwa (1) hanya akan memasukkan "Juli" di Gemfile.lock (dan karena itu dalam aplikasi) dalam lingkungan pengembangan. Jadi saat Anda berlaribundle install , Anda akan melihat "Juli" tidak hanya di bawah PATH tetapi juga di bawah DEPENDENSI, tetapi hanya dalam pengembangan. Dalam produksi, itu tidak akan ada sama sekali. Namun, ketika Anda menggunakan (2), Anda akan melihat "Juli" hanya di PATH, bukan di DEPENDENSI, tetapi itu akan muncul ketika Anda bundle installdari lingkungan produksi (yaitu di beberapa permata lain yang termasuk milik Anda sebagai ketergantungan), tidak hanya pengembangan.

Ini hanya pengamatan saya dan saya tidak bisa sepenuhnya menjelaskan mengapa semua ini terjadi tetapi saya menyambut komentar lebih lanjut.

Tampaknya tidak ada dokumen yang jelas berbicara tentang Gemfile.lockformat. Mungkin karena Gemfile.lockitu hanya digunakan oleh bundel secara internal.

Namun, karena Gemfile.locksnapshot Gemfile, yang berarti semua informasinya harus berasal Gemfile(atau dari nilai default jika tidak ditentukan dalam Gemfile).

Sebab GEM, daftar semua dependensi yang Anda perkenalkan secara langsung atau tidak langsung di Gemfile. remotedi bawah GEMmemberitahu di mana mendapatkan permata, yang ditentukan oleh sumber di Gemfile.

Jika permata tidak diambil remote, PATHberi tahu lokasi untuk menemukannya. PATHinfo 's berasal dari jalan di Gemfilesaat Anda menyatakan ketergantungan.

Dan PLATFORMdari sini .

Sebab DEPENDENCIES, snapshot dependensi diselesaikan dengan bundel.

Apa arti tanda seru setelah nama permata di grup 'DEPENDECIES'?

Tanda seru muncul ketika permata dipasang menggunakan sumber selain " https://rubygems.org ".