Ganti ENV['HOME'] untuk pengembangan aplikasi baris perintah Ruby

Saya sedang membangun aplikasi baris perintah Ruby dengan karakteristik berikut:

  • Ini menggunakan kerangka kerja GLI.
  • Aplikasi ini menggunakan variabel ENV['HOME'] untuk jalur ke direktori home pengguna.
  • File konfigurasi disimpan di bawah direktori home pengguna.
  • Aplikasi ini akan diterapkan ke produksi sebagai Permata.
  • Pengembangan dilakukan pada mesin yang sama yang menggunakan aplikasi dalam produksi.
  • Kombinasi Mentimun, RSpec dan menjalankan aplikasi melalui bundle exec bin/app_name digunakan untuk menguji skrip dalam pengembangan.

Aplikasi ini memanipulasi file. Tujuan saya adalah memastikan instance pengembangan hanya beroperasi pada lingkungan pengembangan/pengujiannya sendiri. Saya yakin pendekatan yang baik adalah dengan mengganti ENV['HOME'] saat skrip dijalankan untuk pengembangan.

Apakah ada cara untuk mengganti variabel ENV['HOME'] sehingga, bagaimanapun caranya, setiap kali skrip dijalankan di direktori pengembangannya, skrip tidak menggunakan jalur ENV['HOME'] yang sebenarnya?


person Alan W. Smith    schedule 26.05.2014    source sumber
comment
Apakah Anda memikirkan cara untuk menentukan apakah skrip tersebut merupakan versi pengembangan atau bukan?   -  person matt    schedule 26.05.2014
comment
@matt, itu bagian dari trik yang saya coba cari tahu. (Saya relatif baru dalam hal semacam ini di Ruby.) Saya pikir saya bisa memiliki file yang bertindak sebagai saklar yang ada di dev, tetapi tidak diterapkan ke produksi. Saya sedang mengerjakan eksperimen dengan pendekatan itu sekarang.   -  person Alan W. Smith    schedule 26.05.2014


Jawaban (1)


Cara saya melakukan ini adalah dengan menjauhkan hal-hal khusus pengembangan dari kode aplikasi sebenarnya, tetapi memiliki Rakefile untuk digunakan untuk pengujian selama pengembangan. Di sana Anda dapat memastikan lingkungan diatur dengan tepat, seperti:

desc "Run the app"
task :exec do
  ENV['HOME']= "somewhere else"
  exec "./bin/your_binary"
end

Anda kemudian akan menjalankan rake exec (atau memberi nama yang lebih baik pada tugas tersebut) untuk menjalankan versi pengembangan, sambil tetap dapat menjalankan versi sebenarnya. Jika Anda menyimpan direktori pengembangan bin dari PATH Anda, seharusnya tidak ada peluang untuk mencampuradukkan kedua perintah tersebut.

Jika Anda ingin dapat menjalankan versi pengembangan secara langsung, Anda dapat menggunakan fakta bahwa ketika Anda menjalankan biner permata, file sebenarnya yang dieksekusi adalah file pembungkus yang dibuat oleh Rubygems. Anda dapat memeriksanya dengan idiom __FILE__ == $0 di bagian atas executable Anda:

if __FILE == $0
  # executing directly, probably in dev environment
  ENV['HOME'] = "somewhere else"
end

Saat memanggil file Anda secara langsung, lingkungan akan diganti, saat memanggil permata yang diinstal $0 akan menjadi file pembungkus sehingga lingkungan asli akan digunakan.

Cara "normal" untuk melakukan ini adalah dengan mengatur lingkungan dari shell Anda, misalnya. di pesta:

$ HOME='somewhere else' ./bin/the_executable

Bahayanya di sini tentu saja adalah Anda mungkin lupa mengatur lingkungan, sehingga menyebabkan Anda membuang beberapa file Anda ke sampah. Anda dapat menyiasatinya dengan mengatur lingkungan baru untuk seluruh tampilan Anda:

$ export HOME='somewhere else'
$ ./bin/the_executable

tapi ini kemungkinan akan mempengaruhi alat lain yang menggunakan HOME jadi tidak disarankan.

Saran saya adalah memilih opsi Rakefile, dengan opsi __FILE == $0 sebagai pilihan kedua.

person matt    schedule 26.05.2014
comment
Saya sedang mengerjakan pendekatan ini. Juga, untuk beberapa kasus, saya menambahkan pemeriksaan untuk file yang hanya ada di lingkungan pengembang. Ini secara efektif merupakan saklar mematikan jika file itu ada dan ENV['HOME'] belum diperbarui. Jika saya tidak memicunya secara tidak sengaja untuk sementara waktu, saya akan menghapusnya, tetapi untuk saat ini, saya menyukai gagasan tentang lapisan ekstra yang melindungi saya dari diri saya sendiri saat saya mempelajari Ruby. - person Alan W. Smith; 28.05.2014