bundle-install - Instal dependensi yang ditentukan di Gemfile Anda
bundle install [--binstubs[=DIRECTORY]] [--clean] [--deployment] [--frozen] [--full-index] [--gemfile=GEMFILE] [--jobs=NUMBER] [--local] [--no-cache] [--no-prune] [--path PATH] [--quiet] [--redownload] [--retry=NUMBER] [--shebang] [--standalone[=GROUP[ GROUP...]]] [--system] [--trust-policy=POLICY] [--with=GROUP[ GROUP...]] [--without=GROUP[ GROUP...]]
Instal permata yang ditentukan di Gemfile Anda (5). Jika ini adalah pertama kalinya Anda menjalankan penginstalan bundel (dan Gemfile.lock tidak ada), Bundler akan mengambil semua sumber jarak jauh, menyelesaikan dependensi, dan menginstal semua permata yang diperlukan.
Jika Gemfile.lock memang ada, dan Anda belum memperbarui Gemfile(5), Bundler akan mengambil semua sumber jarak jauh, tetapi menggunakan dependensi yang ditentukan di Gemfile.lock alih-alih menyelesaikan ketergantungan.
Jika Gemfile.lock memang ada, dan Anda telah memperbarui Gemfile(5), Bundler akan menggunakan dependensi di Gemfile.lock untuk semua permata yang tidak Anda perbarui , tetapi akan menyelesaikan kembali dependensi permata yang Anda perbarui. Anda dapat menemukan informasi selengkapnya tentang proses pembaruan ini di bawah PEMBARUAN KONSERVATIF.
Opsi --clean, --deployment, --frozen, --no-prune, --path, --shebang, --system, --with dan --with tidak digunakan lagi karena hanya masuk akal jika diterapkan ke setiap bun berikutnya dle install berjalan secara otomatis dan itu membutuhkan bundler untuk mengingatnya secara diam-diam. Karena bundler tidak lagi mengingat flag CLI di versi mendatang, bundle config (lihat bundle-config(1)) harus digunakan untuk menerapkannya secara permanen.
Binstub adalah skrip yang membungkus file yang dapat dieksekusi. Bundler membuat file Ruby kecil (binstub) yang memuat Bundler, menjalankan perintah, dan meletakkannya di bin/. Ini memungkinkan Anda menautkan binstub di dalam aplikasi ke versi permata yang tepat yang dibutuhkan aplikasi.
Membuat direktori (defaultnya adalah ~/bin) dan menempatkan semua executable dari permata di sana. Eksekusi ini berjalan dalam konteks Bundler. Jika digunakan, Anda dapat menambahkan direktori ini ke variabel PATH lingkungan Anda. Misalnya, jika permata Rail dilengkapi dengan eksekusi Rail, tanda ini akan membuat eksekusi bin/Rail yang memastikan bahwa semua dependensi yang dirujuk akan diselesaikan menggunakan permata yang dibundel.
Saat menyelesaikan instalasi, Bundler akan menghapus semua permata yang tidak ada di Gemfile(5) saat ini. Jangan khawatir, permata yang sedang digunakan tidak akan dihapus.
Opsi ini tidak digunakan lagi dan mendukung setelan bersih.
Dalam mode penerapan, Bundler akan 'meluncurkan' bundel untuk produksi atau penggunaan CI. Silakan periksa dengan hati-hati jika Anda ingin opsi ini diaktifkan di lingkungan pengembangan Anda.
Opsi ini tidak digunakan lagi dan mendukung setelan penerapan.
Unduh paksa setiap permata, meskipun versi yang diperlukan sudah tersedia secara lokal.
Jangan izinkan Gemfile.lock diperbarui setelah instalasi ini. Keluar bukan nol jika akan ada perubahan pada Gemfile.lock.
Opsi ini tidak digunakan lagi dan mendukung setelan beku.
Bundler tidak akan memanggil titik akhir API Rubygems (default) tetapi mengunduh dan meng-cache file indeks (saat ini besar) dari semua permata. Performa dapat ditingkatkan untuk bundel besar yang jarang berubah dengan mengaktifkan opsi ini.
Lokasi Gemfile(5) yang harus digunakan Bundler. Ini default ke Gemfile(5) di direktori kerja saat ini. Secara umum, Bundler akan berasumsi bahwa lokasi Gemfile(5) juga merupakan akar proyek dan akan mencoba menemukan Gemfile.lock dan vendor/cache relatif terhadap lokasi ini.
Jumlah maksimum pekerjaan pengunduhan dan penginstalan paralel. Standarnya adalah jumlah prosesor yang tersedia.
Jangan mencoba terhubung ke rubygems.org. Sebagai gantinya, Bundler akan menggunakan permata yang sudah ada di cache Rubygems atau di vendor/cache. Perhatikan bahwa jika ada permata khusus platform yang sesuai di rubygems.org, permata itu tidak akan ditemukan.
Paksa penggunaan permata yang dipasang secara lokal, atau permata yang sudah ada di cache Rubygems atau di vendor/cache, saat penyelesaian, bahkan jika versi yang lebih baru tersedia dari jarak jauh. Hanya coba sambungkan ke rubygems.org untuk permata yang tidak ada secara lokal.
Jangan perbarui cache di vendor/cache dengan permata yang baru dibundel. Ini tidak menghapus permata apa pun di cache tetapi menjaga agar permata yang baru dibundel tidak di-cache selama penginstalan.
Jangan hapus permata basi dari cache saat penginstalan selesai.
Opsi ini tidak digunakan lagi karena setelan no_prune.
Lokasi untuk menginstal permata yang ditentukan. Ini default untuk pengaturan Rubygems. Bundler membagikan lokasi ini dengan Rubygems, gem install ... juga akan menginstal gem di sana. Oleh karena itu, permata yang dipasang tanpa pengaturan --path ... akan muncul dengan memanggil daftar permata. Oleh karena itu, permata yang dipasang di lokasi lain tidak akan terdaftar.
Opsi ini tidak digunakan lagi karena setelan jalur.
Jangan cetak informasi kemajuan ke keluaran standar. Sebagai gantinya, Bundler akan keluar menggunakan kode status ($?).
Coba lagi permintaan jaringan atau git yang gagal sebanyak jumlah kali.
Menggunakan ruby yang dapat dieksekusi yang ditentukan (biasanya ruby) untuk mengeksekusi skrip yang dibuat dengan --binstubs. Selain itu, jika Anda menggunakan --binstubs bersama dengan --shebang jruby executable ini akan diubah menjadi jruby sebagai gantinya.
Opsi ini tidak digunakan lagi karena setelan shebang.
Membuat bundel yang dapat berfungsi tanpa bergantung pada Rubygems atau Bundler saat runtime. Daftar grup yang dipisahkan ruang untuk diinstal harus ditentukan. Bundler membuat direktori bernama bundel dan memasang bundel di sana. Ini juga menghasilkan file bundle/bundler/setup.rb untuk menggantikan penyiapan Bundler sendiri dengan cara yang diperlukan. Menggunakan opsi ini secara implisit menyetel jalur, yang merupakan [opsi yang diingat][OPSI YANG DIINGAT].
Instal permata yang ditentukan dalam bundel ke lokasi Rubygems sistem. Ini mengesampingkan konfigurasi sebelumnya dari --path.
Opsi ini tidak digunakan lagi karena setelan sistem.
Terapkan kebijakan kebijakan keamanan Rubygems, di mana kebijakan adalah salah satu dari Keamanan Tinggi, Keamanan Sedang, Keamanan Rendah, AlmostNoSecurity, atau NoSecurity. Untuk detail lebih lanjut, silakan lihat dokumentasi penandatanganan Rubygems yang ditautkan di bawah LIHAT JUGA.
Daftar grup yang dipisahkan ruang yang mereferensikan permata untuk diinstal. Jika grup opsional diberikan, itu diinstal. Jika suatu grup diberikan yang ada dalam daftar grup yang diingat yang diberikan kepada --tanpa, itu dihapus dari daftar itu.
Opsi ini tidak digunakan lagi karena setelan with.
Daftar grup referensi permata yang dipisahkan ruang untuk dilewati selama penginstalan. Jika suatu grup diberikan yang ada dalam daftar grup yang diingat yang diberikan kepada --with, itu dihapus dari daftar itu.
Opsi ini tidak digunakan lagi karena setelan tanpa.
Default Bundler dioptimalkan untuk pengembangan. Untuk beralih ke default yang dioptimalkan untuk penerapan dan CI, gunakan tanda --deployment. Jangan aktifkan mode deployment pada mesin pengembangan, karena akan menyebabkan error saat Gemfile(5) dimodifikasi.
Diperlukan Gemfile.lock. Untuk memastikan bahwa versi yang sama dari permata yang Anda kembangkan dan uji juga digunakan dalam penerapan, diperlukan Gemfile.lock. Ini terutama untuk memastikan bahwa Anda ingat untuk memeriksa Gemfile.lock Anda ke kontrol versi.
Gemfile.lock harus mutakhir Dalam pengembangan, Anda dapat memodifikasi Gemfile(5) dan menjalankan kembali bundle install untuk memperbarui secara konservatif snapshot Gemfile.lock Anda. Dalam penerapan, Gemfile.lock Anda harus diperbarui dengan perubahan yang dibuat di Gemfile(5).
Permata dipasang ke vendor/paket bukan ke lokasi sistem default Anda Dalam pengembangan, akan lebih mudah untuk membagikan permata yang digunakan dalam aplikasi Anda dengan aplikasi lain dan skrip lain yang berjalan di sistem. Dalam penyebaran, isolasi adalah standar yang lebih penting. Selain itu, pengguna yang menerapkan aplikasi mungkin tidak memiliki izin untuk memasang permata ke sistem, atau server web mungkin tidak memiliki izin untuk membacanya. Akibatnya, bundle install --deployment memasang permata ke direktori vendor/bundle di aplikasi. Ini dapat diganti menggunakan opsi --path.
Secara default, pemasangan bundel akan memasang semua permata di semua grup di Gemfile(5), kecuali yang dideklarasikan untuk platform yang berbeda.
Namun, Anda dapat secara eksplisit memberi tahu Bundler untuk melewati penginstalan grup tertentu dengan opsi --tanpa. Opsi ini menggunakan daftar grup yang dipisahkan ruang.
Meskipun opsi --tanpa akan melewatkan memasang permata di grup yang ditentukan, opsi ini masih akan mengunduh permata tersebut dan menggunakannya untuk menyelesaikan dependensi dari setiap permata di Gemfile Anda (5).
Ini agar menginstal kumpulan grup yang berbeda di komputer lain (seperti server produksi) tidak akan mengubah permata dan versi yang telah Anda kembangkan dan uji.
Bundler menawarkan jaminan yang sangat kuat bahwa kode pihak ketiga yang Anda jalankan dalam pengembangan dan pengujian juga merupakan kode pihak ketiga yang Anda jalankan dalam produksi. Anda dapat memilih untuk mengecualikan beberapa kode tersebut di lingkungan yang berbeda, tetapi Anda tidak akan pernah terjebak oleh versi berbeda dari kode pihak ketiga yang digunakan di lingkungan yang berbeda.
Untuk ilustrasi sederhana, perhatikan Gemfile(5) berikut:
source 'https://rubygems.org'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
endDalam hal ini, sinatra bergantung pada versi Rack apa pun (>= 1.0), sedangkan rack-perftools-profiler bergantung pada 1.x ( ~> 1.0).
Saat Anda menjalankan pemasangan bundel --tanpa produksi dalam pengembangan, kami juga melihat ketergantungan rack-perftools-profiler. Dengan begitu, Anda tidak menghabiskan seluruh waktu Anda untuk mengembangkan melawan Rack 2.0, menggunakan API baru yang tidak tersedia di Rack 1.x, hanya agar Bundler beralih ke Rack 1.2 saat grup produksi ada digunakan.
Ini seharusnya tidak menyebabkan masalah apa pun dalam praktiknya, karena kami tidak berusaha untuk memasang permata di grup yang dikecualikan, dan hanya mengevaluasi sebagai bagian dari proses penyelesaian ketergantungan.
Ini juga berarti bahwa Anda tidak dapat menyertakan versi yang berbeda dari permata yang sama dalam grup yang berbeda, karena hal itu akan menghasilkan kumpulan ketergantungan yang berbeda yang digunakan dalam pengembangan dan produksi. Karena keanehan dari proses resolusi ketergantungan, ini biasanya mempengaruhi lebih dari permata yang Anda daftarkan di Gemfile Anda (5), dan dapat (secara mengejutkan) mengubah permata yang Anda gunakan secara radikal.
Saat Anda menjalankan pemasangan bundel, Bundler akan mempertahankan nama lengkap dan versi semua permata yang Anda gunakan (termasuk dependensi permata yang ditentukan dalam Gemfile(5)) ke dalam file bernama Gemfile.lock.
Bundler menggunakan file ini dalam semua panggilan berikutnya ke pemasangan bundel, yang menjamin bahwa Anda selalu menggunakan kode yang persis sama, meskipun aplikasi Anda berpindah antar mesin.
Karena cara resolusi dependensi bekerja, bahkan perubahan yang tampaknya kecil (misalnya, pembaruan ke titik-rilis dependensi permata di Gemfile(5) Anda) dapat menghasilkan permata yang sangat berbeda yang diperlukan untuk memenuhi semua dependensi.
Akibatnya, Anda HARUS memeriksa Gemfile.lock Anda ke kontrol versi, baik di aplikasi maupun permata. Jika tidak, setiap mesin yang memeriksa repositori Anda (termasuk server produksi Anda) akan menyelesaikan semua dependensi lagi, yang akan menghasilkan versi berbeda dari kode pihak ketiga yang digunakan jika salah satu permata di Gemfile(5) atau dependensinya telah diperbarui.
Saat Bundler pertama kali dikirimkan, Gemfile.lock disertakan dalam file .gitignore yang disertakan dengan permata yang dihasilkan. Namun, seiring berjalannya waktu, menjadi jelas bahwa praktik ini memaksakan rasa sakit dari ketergantungan yang rusak ke kontributor baru, sementara membiarkan kontributor yang ada berpotensi tidak menyadari masalah tersebut. Karena pemasangan bundel biasanya merupakan langkah pertama menuju kontribusi, kesulitan ketergantungan yang rusak akan membuat kontributor baru enggan untuk berkontribusi. Akibatnya, kami telah merevisi panduan kami untuk pembuat permata untuk sekarang merekomendasikan memeriksa kunci untuk permata.
Ketika Anda membuat perubahan pada Gemfile(5) dan kemudian menjalankan bundle install, Bundler hanya akan memperbarui permata yang Anda ubah.
Dengan kata lain, jika permata yang tidak Anda ubah berfungsi sebelum Anda memanggil pemasangan bundel, permata itu akan terus menggunakan versi semua dependensi yang sama persis seperti yang digunakan sebelum memperbarui.
Mari kita lihat sebuah contoh. Inilah Gemfile asli Anda (5):
source 'https://rubygems.org'
gem 'actionpack', '2.3.8'
gem 'activemerchant'Dalam hal ini, actionpack dan activemerchant bergantung pada activesupport. Permata actionpack bergantung pada activesupport 2.3.8 dan rack ~> 1.1.0, sedangkan permata activemerchant bergantung pada activesupport >= 2.3.2, braintree >= 2.0.0, dan builder >= 2.0.0.
Saat dependensi diselesaikan pertama kali, Bundler akan memilih activesupport 2.3.8, yang memenuhi persyaratan kedua permata di Gemfile(5) Anda.
Selanjutnya, Anda memodifikasi Gemfile(5) Anda menjadi:
source 'https://rubygems.org'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'Permata actionpack 3.0.0.rc memiliki sejumlah dependensi baru, dan memperbarui dependensi activesupport menjadi = 3.0.0.rc dan dependensi rack menjadi ~> 1.2.1.
Saat Anda menjalankan pemasangan bundel, Bundler memperhatikan bahwa Anda mengubah permata actionpack, tetapi bukan permata activemerchant. Itu mengevaluasi permata yang saat ini digunakan untuk memenuhi persyaratannya:
juga digunakan untuk memenuhi ketergantungan pada activemerchant, yang tidak diperbarui
saat ini tidak digunakan untuk memenuhi ketergantungan lain
Karena Anda tidak secara eksplisit meminta untuk memperbarui activemerchant, Anda tidak akan mengharapkannya tiba-tiba berhenti bekerja setelah memperbarui actionpack. Namun, memenuhi dependensi baru activesupport 3.0.0.rc actionpack memerlukan pembaruan salah satu dependensinya.
Meskipun activemerchant mendeklarasikan dependensi yang sangat longgar yang secara teoritis cocok dengan activesupport 3.0.0.rc, Bundler memperlakukan permata di Gemfile(5) Anda yang tidak berubah sebagai unit atom bersama dengan dependensinya. Dalam hal ini, dependensi activemerchant diperlakukan sebagai activemerchant 1.7.1 + activesupport 2.3.8, jadi bundle install akan melaporkan bahwa ia tidak dapat memperbarui actionpack.
Untuk memperbarui actionpack secara eksplisit, termasuk dependensinya yang masih bergantung pada permata lain di Gemfile(5), jalankan bundle update actionpack (lihat bundle update(1)).
Ringkasan: Secara umum, setelah melakukan perubahan pada Gemfile(5) , pertama-tama Anda harus mencoba menjalankan bundle install, yang akan menjamin bahwa tidak ada permata lain di Gemfile(5) yang terpengaruh oleh perubahan tersebut. Jika tidak berhasil, jalankan bundle update(1) bundle-update.1.html.
Dokumen pemasangan permata http://guides.rubygems.org/rubygems-basics/#installing-gems
Dokumen penandatanganan Rubygems http://guides.rubygems.org/security/