LinuxにおけるRubyのgemが何かとややこしい。Bundler、Gemfile、gemspec、Rakefileとは？ (original) (raw)
⇧ ソフトウェア開発者としては、「Real Time Linux」に依存する機能を開発する上での環境構築が容易になるのであれば、嬉しいことですが。
「degrade（退化させる）」乃至は、「regression（退化、後戻り）」が起きておらず、性能面、セキュリティ面も影響がないのであれば、Linuxカーネルに組み込まれたのは、良いことのように思われますな。
Rubyのgemとは
Rubyの公式のドキュメントによると、
⇧とあり、「gem」という用語は
の2つの意味を持つらしいですと。
Wikipediaによると、
⇧ とあり、RubyGemsとのやり取りをする際に「gem」コマンドを使っていると。
■旧い構成
■新しい構成
⇧ となってるらしい。
基本的には、RubyGemsというシステムが管理、公開しているGemライブラリをダウンロードしてきて利用する感じになるってことかね？
Bundler、Gemfile、gemspec、Rakefileとかって何なの？
で、Rubyのプロジェクトで目にするのが、
- Bundler
- Gemfile
- gemspec
- Rakefile
といった用語なんだけど、こ奴らは一体何者なのか？
「Bundler」はというと、
⇧ Rubyのアプリケーションが動作する際の、環境依存を無くしてくれると謳っている。
何だろう、Javaで言うところの「Java 仮想マシン（JVM：Java Virtual Machine）」のような役割を実現しているということになるんだろうか？
⇧ とあるように、Javaにおいては、環境依存の無い動作を実現してるのが「Java 仮想マシン（JVM：Java Virtual Machine）」らしいですと。
勿論、完全に実現できているわけでは無いので、「ファイルシステム」に依存したソースコードなどは（「.sh」を実行する処理などは、Linux環境でしか動作しないなど）、一部の環境でしか動かない。
話が脱線しましたが、「Bundler」は「RubyGems」の一部かと思いきや、
⇧ 上記のページを見た感じでは、明確に区別されてるように思えますと。
続いて、「Gemfile」はというと、
⇧「Bundler」の機能を実現する一部ということになる感じなんですかね？
「gemspec」「Rakefile」なども、「Bundler」の機能を実現する一部ってことになるんかな？
このあたり、発祥が不明なので、よく分からんですな...
とりあえず、「Bundler」に関連する登場人物たちということになるんですかね？
まとめると、
- Bundler
- Gemfile
- Gemfile.lock
- gemspec
- Rakefile
「Bundler」特有の用語ってことになるんですかね？
Gemのインストール方法は2種類あるということ？
で、
⇧ 上記サイト様にありますように、RubyGemsとのやり取りは、唯一、
- gem command
のみでありますと。
なので、「Bundler」も内部的に、gem command を利用していると思われますが、Gemをインストールする方法としては、
- gem command直接実行する
- Bundlerを利用する
の2つの方法が用意されているという認識で良いのかしら？
Ruby界隈の事情が全く分からんので何とも言えませんが...
LinuxにおけるRubyプロジェクトのGemどう管理すれば？
で、最近、
- Bundlerのインストールだと動かない
- gem installだと動く
という事象に遭遇して、途方に暮れてましたと。
そりゃ、「Bundler」でGemを管理して動かせるなら動かしたいよ...
皆様のご推察の通り、
⇧「Oxidized」でございます。
そもそも、公式のドキュメントでも、「Bundler」を使っていないんよね...
「Ruby」が適当過ぎるのか、「Oxidized」が適当過ぎるのか、それが問題だ、と言いたくなってしまうぐらい、カオスな状況ですと。
頼むから、環境構築で不毛な時間を浪費させないで欲しい...
RubyがGemを参照する仕組みが知りたいんだが...
そもそも、RubyがGemを参照する仕組みが把握できていないという...
ChatGPTに聞いた感じでは、
- GEM_HOME
- GEM_PATH
の2つの「環境変数」が、Gemを参照する上で関係してくるらしい。
stackoverflowによると、
⇧ とあり、Rubyが実行の際に参照するGemは、「環境変数」の「GEM_PATH」の値を元にしているらしいですと。
で、「環境変数」の「GEM_HOME」がGemがインストールされる場所らしく、ChatGPTに聞いた感じでは、
Linuxのユーザー: GEM_HOME = 1: 1
⇧ ということらしく、Linuxのユーザー毎に異なるらしい。
ネットの情報でよく見かける「bundle install --path vendor/bundle」については、
⇧ 非推奨となっているが、Gemをインストールする場所を指定しているらしいので、「環境変数」の「GEM_HOME」を無視してインストールしているということらしい。
で、「Bundler」の上記のドキュメントで「GEM_PATH」についての記載が無いところをみると、おそらく「bundle install --path vendor/bundle」を実行したとしても、Gemがインストールされるだけであって、「環境変数」の「GEM_PATH」に対してインストールされたGemを参照するパスは自動で追加されないっぽい。
だから、Ruby実行時に、Gemが参照できないよ、って怒られたってことなんですかね？
ちなみに、「bundle install --path」の非推奨については、
⇧ 上記サイト様が対応を記載してくれておりました。
Gemが複数箇所にインストールされている場合、どちらも「環境変数」の「GEM_PATH」にGemの参照先を設定している場合、どういう挙動になるのか？
ChatGPTに確認したところ、
⇧ 先に設定されている方が優先されるらしい。
「環境変数」の「GEM_PATH」の確認については、
⇧ 上記サイト様によりますと、
- gem environment
→ Bundlerに関連する情報を除く - bundle env
→ Bundlerに関連する情報
という感じで、「Bundler」で管理してるかどうかの区別は、差分で確認する感じになるんかね？
Linux環境なら「printenv」とかで「環境変数」の「GEM_PATH」の値の全量は確認できそうな気がしますが、内訳を確認するには、「gem environment」や「bundle env」が必要になると。
他にも、
- LOAD_PATH
- RUBYLIB
- RUBYPATH
のあたりについて、役割や関係性が分からんのよね...
「環境変数」の「RUBYLIB」、「RUBYPATH」については、
⇧ Rubyの公式のドキュメントに載っていた。
「LOAD_PATH」については、
⇧ Rubyの組み込みライブラリで用意されている変数らしい。
ChatGPTに確認したところ、
■RubyプログラムでGemが読み込まれるフロー
- Rubyプログラム実行:
- GEM_PATHの確認:
- LOAD_PATHの設定:
- requireの解決:
- プログラム内で require や require_relative を使用してGemを読み込むと、 Rubyは「LOAD_PATH」を順に検索し、指定されたファイルを見つけます。
- Gemのファイルが読み込まれる:
- 最初に見つかったファイルが読み込まれ、そのGemの機能が利用可能になります。
という流れになるそうな。
Ruby、何かとややこしい...
結局のところ、Rubyのプログラムが実行されるために必要な情報が分かり辛いんよね...
gemに種類があるらしい
何やら、
⇧ とのことで、gem自体に種類があるそうな。
Ruby、徒労感が半端ない...
毎度モヤモヤ感が半端ない…
今回はこのへんで。