Foreman: Perbarui ketergantungan thor

Dibuat pada 4 Jun 2019  ·  15Komentar  ·  Sumber: ddollar/foreman

mandor tergantung pada versi lama thor yang tidak kompatibel dengan permata terbaru seperti Rails 6. Saran yang berlaku tampaknya untuk meninggalkan mandor dari Gemfile, tapi ini sepertinya solusi. (Kami memiliki proyek selama bertahun-tahun dengan mandor di Gemfile, tidak ada masalah.)

Bagaimanapun, mengapa foreman.gemspec mereferensikan versi thor dari 2014? Mengapa tidak memutakhirkannya?

Lihat juga #452, #653, (dan #688, #725, dll.), serta memengaruhi proyek lain, misalnya https://github.com/bkeepers/dotenv/issues/324

Komentar yang paling membantu

@ddollar Saya tidak setuju dengan https://github.com/ddollar/foreman/wiki/Don 't-Bundle-Foreman.

Mandor di @cultureamp adalah alat pengembang, seperti rubocop, rspec-rails, mentimun, factory_bot, dll. Adalah _nyaman_ untuk menentukan ini di Gemfile , karena kemudian akan tersedia untuk kita gunakan segera , sama seperti alat-alat lainnya.

Saya akan menentukannya seperti ini:

group :development do
  gem 'foreman', require: false
end

Dengan menambahkannya ke grup development itu berarti tidak tersedia pada produksi, dan bukan vektor kerentanan.


Jadi dengan mengingat hal itu, itu berarti bahwa Gemfile.lock menerima dependensi ini:

foreman (0.85.0)
  thor (~> 0.19.1)

Ini menyebabkan konflik dengan permata railties 6.0 baru, karena memiliki ketergantungan pada thor dari >= 0.20.3, < 2.0 .

Saya sangat yakin bahwa foreman _harus_ ditempatkan dalam Gemfile aplikasi karena _itu adalah alat pengembang_ dan saya juga sangat yakin bahwa ketergantungan thor mandor harus diperbarui, atau setidaknya dilonggarkan.

Semua 15 komentar

Apakah ini masih dipertahankan?

@alaxalves kami baru saja beralih ke forego , tampaknya menjadi pengganti drop-in.

@alaxalves kami baru saja beralih ke forego , tampaknya menjadi pengganti drop-in.

@mfilej Ini bagus, tapi bagaimana kita tetap menggunakan Foreman di aplikasi Rails?

@alaxalves Apa sebenarnya yang Anda maksud dengan "menggunakan di aplikasi Rails"? Apakah Anda menggunakan untuk sesuatu selain menjalankan proses? Bagi kami itu hanya masalah menginstal forego pada mesin dan server pengembangan kami (gambar buruh pelabuhan) dan mengubah perintah dari foreman start menjadi forego start .

@alaxalves Apa sebenarnya yang Anda maksud dengan "menggunakan di aplikasi Rails"? Apakah Anda menggunakan untuk sesuatu selain menjalankan proses? Bagi kami itu hanya masalah menginstal forego pada mesin dan server pengembangan kami (gambar buruh pelabuhan) dan mengubah perintah dari foreman start menjadi forego start .

Maksud saya menggunakannya sebagai permata.

@alaxalves maaf, saya tidak tahu apa artinya. Dalam kasus kami, kami baru saja menjatuhkan permata mandor dari file permata kami. Apakah ada sesuatu dalam kode Anda yang bergantung pada permata mandor?

@alaxalves maaf, saya tidak tahu apa artinya. Dalam kasus kami, kami baru saja menjatuhkan permata mandor dari file permata kami. Apakah ada sesuatu dalam kode Anda yang bergantung pada permata mandor?

Ya, saya sudah menggunakannya. Tapi saya akan mulai menggunakan forego. Saya hanya tidak ingin menginstalnya sebagai pkg atau semacamnya. Saya ingin tetap menggunakan sebagai dependensi yang ditentukan dalam Gemfile saya. Bagaimanapun, terima kasih atas waktunya :senyum:

Saya melihat masalah yang sama persis saat melakukan peningkatan ke Rails 6.0.0, yang bergantung pada versi thor yang lebih baru. Bundler menyelesaikannya dengan menurunkan peringkat mandor, dotenv, dan thor. Saya sudah mencoba memaksa mandor versi terbaru di Gemfile dan ini menunjukkan masalah ketergantungan:

Bundler could not find compatible versions for gem "thor":
  In snapshot (Gemfile.lock):
    thor (= 0.20.3)

  In Gemfile:
    foreman (~> 0.85.0) was resolved to 0.85.0, which depends on
      thor (~> 0.19.1)

    rspec-rails was resolved to 3.8.2, which depends on
      railties (>= 3.0) was resolved to 6.0.0, which depends on
        thor (>= 0.20.3, < 2.0)

Menjalankan pembaruan bundel juga tidak menyelesaikan masalah.

Sejauh yang saya ketahui Forego tidak ditulis dalam Ruby jadi itu bukan solusi yang bagus karena akan menambah ketergantungan lain pada proyek.

Saya sangat menyarankan agar Anda tidak memasukkan foreman di Gemfile Anda. Saya telah menulis alasan saya di sini:

https://github.com/ddollar/foreman/wiki/Don 't-Bundle-Foreman

Besar. Saya telah melihat tulisan Anda dan itu sangat masuk akal. Terima kasih telah mengklarifikasi itu... dan terima kasih telah menempatkan mandor di luar sana!

Saya sangat menyarankan agar Anda tidak memasukkan foreman di Gemfile Anda. Saya telah menulis alasan saya di sini:

https://github.com/ddollar/foreman/wiki/Don 't-Bundle-Foreman

Mengapa tidak menggunakan gem 'foreman', require: false alih-alih tidak memasukkannya ?
Itulah yang saya gunakan untuk banyak alat dev (seperti linter, dll ...), bahkan beberapa dokumentasi permata tampaknya baik-baik saja dengan require: false (lih: https://github.com/rubocop-hq/rubocop #instalasi, https://github.com/sds/haml-lint#installation)

@ddollar Saya tidak setuju dengan https://github.com/ddollar/foreman/wiki/Don 't-Bundle-Foreman.

Mandor di @cultureamp adalah alat pengembang, seperti rubocop, rspec-rails, mentimun, factory_bot, dll. Adalah _nyaman_ untuk menentukan ini di Gemfile , karena kemudian akan tersedia untuk kita gunakan segera , sama seperti alat-alat lainnya.

Saya akan menentukannya seperti ini:

group :development do
  gem 'foreman', require: false
end

Dengan menambahkannya ke grup development itu berarti tidak tersedia pada produksi, dan bukan vektor kerentanan.


Jadi dengan mengingat hal itu, itu berarti bahwa Gemfile.lock menerima dependensi ini:

foreman (0.85.0)
  thor (~> 0.19.1)

Ini menyebabkan konflik dengan permata railties 6.0 baru, karena memiliki ketergantungan pada thor dari >= 0.20.3, < 2.0 .

Saya sangat yakin bahwa foreman _harus_ ditempatkan dalam Gemfile aplikasi karena _itu adalah alat pengembang_ dan saya juga sangat yakin bahwa ketergantungan thor mandor harus diperbarui, atau setidaknya dilonggarkan.

Bahkan jika Foreman tidak boleh dimasukkan ke dalam Gemfiles, apa gunanya menjaganya tetap bergantung pada versi lama Thor yang sudah ketinggalan zaman?

Perubahan apa pun dapat menimbulkan bug, jadi saya akan membalikkan pertanyaan ini. Dengan tidak adanya kerentanan keamanan atau fitur baru yang diinginkan, apa keuntungan meningkatkan ketergantungan yang dapat menyebabkan perubahan yang melanggar?

  1. Pustaka yang lebih lama lebih sulit untuk ditingkatkan. Semakin lama Anda menunggu, semakin sulit ketika Anda benar-benar harus/memutuskan untuk meningkatkan. (Jika tidak akan lebih sulit di masa depan, itu karena perpustakaan tidak memiliki banyak perubahan yang tidak kompatibel, jadi sekarang juga tidak akan sulit.) Masuk akal untuk tidak membuang waktu pada siklus peningkatan yang terlalu sering, tetapi enam tahun adalah waktu yang lama.

  2. Kerentanan keamanan dalam versi perangkat lunak lama yang acak cenderung tidak ditemukan secara publik, karena orang tidak menggunakannya atau melihat ke dalamnya, tetapi kerentanan tetap ada. (Peringatan untuk mainframe kuno, dll. tetapi ini adalah perangkat lunak Github yang terhubung ke Internet.) Tentu saja, kerentanan keamanan di thor tidak diragukan lagi merupakan prioritas rendah, karena ini adalah alat baris perintah lokal, terutama dalam kasus penggunaan mandor. Tapi ini berarti di bawah kebijakan Anda, thor tidak mungkin ditingkatkan, selamanya. (Kerentanan keamanan dilaporkan di thor, tetapi ditutup karena "Thor adalah alat sistem yang tidak mungkin menerima input pengguna", https://github.com/erikhuda/thor/issues/514).

  3. Tidak kompatibel dengan perpustakaan lain, masalah ada di sini. Ada solusi, tetapi menempatkan mandor di Gemfile jelas merupakan kasus penggunaan yang umum dan berguna. Tampaknya ada permata lain yang bergantung pada mandor dan karenanya harus memasukkannya ke dalam Gemfile mereka. (Ini berpotensi juga memengaruhi kualitas pengujian, jika pengguna memiliki sistem campuran terkini sementara lingkungan pengujian memiliki instalasi kosong dengan versi lama, meskipun mungkin tidak dalam kasus mandor/thor.)

Kesimpulannya, dari perspektif teknis tampaknya seperti panggilan dekat, tetapi dari perspektif sistem dan ekosistem itu penting, dan menjadi lebih seperti tahun-tahun berlalu (dan saya bukan seseorang yang berpikir "lebih baru berarti lebih baik"). Anda mungkin berpikir tidak ada yang akan menggunakan perangkat lunak Anda pada saat ketergantungan thor adalah sepuluh tahun penuh, tetapi Anda juga mendapatkan efek jaminan di mana orang memutuskan untuk berhenti menggunakan mandor karena tidak kompatibel atau tampak tidak terawat.

(Juga, ada kemungkinan berbeda bahwa memutakhirkan ketergantungan akan memakan waktu lima menit dan tidak menimbulkan bug.)

Apakah halaman ini membantu?
0 / 5 - 0 peringkat