RubyKaigi 2023 参加記 #4 - How resolve Gem dependencies in your code?(Day 2)

エンジニアの江草です。

今回は、日本最大の Ruby に関するカンファレンスである RubyKaigi に Wantedly がスポンサードし、いくつかの講演を聴講しています。Wantedly はスポンサーブースを設けていて、アンケートに答えてくださった方にはRubyKaigi 2023 のために描き下ろした技術書をお渡ししており、Twitterをフォローしてくださった方には 過去のTechBookなどを配布しています。

この記事では、柴田さん(@hsbt)による「How resolve Gem dependencies in your code?」をご紹介させていただきます。

予備知識

今回の発表を理解するためにいくつか用語の説明が行われました。

• Gem::Specification: RubyGems の内部実装で使われているクラスで Gem のメタデータを持っている
• gemspec: Gem::Specificationをテキストファイルとして記述したもの
• Resolution: 複数のライブラリの依存を解決すること
• Resolver Engine: 低レベルの依存関係解決を行うエンジン(PubGrubなど)
• Resolver: Resolver Engineの結果を使い、Resolution を行うもの

RubyGems/Bunder のアーキテクチャ

両方とも Resolver Engine の結果を使って Resolver が動作する似たようなアーキテクチャになっています。Resolver Engine に RubyGems は Molinillo、 Bundler は PubGrub を使っているなどの違いがあります。

RubyGems/Bundlerの問題点

遅い

まずそもそも依存関係の解決が遅いという問題があります。例えば RubyGems では require や gem などのメソッドを拡張していることが遅さの原因となっているそうです。高速化のために本来はデバッグ用のオプションである --disable-gems を使う、ということも一部のユーザーの間で行われていました。

RubyGems と Bundler で微妙に仕様が異なったり片方だけバグがあったりする

これはいくつか発表者の方が調査したいくつかの例が挙げられています。

例1 gem install が意図通りに動かない問題

ローカルにある gem をインストールしようとするとき、C拡張を利用しているかつインストール済みのバージョンと同じ defualt gem をインストールしようとすると動かないというバグがありました。

結果としては RubyGems の内部実装で使われている Gem::Specification の派生クラスが多く、それぞれのクラスで持っているフィールドが微妙に異なることに起因するバグでした。

例2 update --conservative の挙動の違い

gem update --conservative を実行すると、すでに依存関係の条件を満たしている gem は更新されません。しかし、bundle update --conservative は指定した gem の依存関係の下にある gem も更新の対象となってしまいます。関連して挙動の違いとして、指定した gem が更新されずに、その gem の依存先の gem だけが更新されてしまうことがあります。これは依存関係がコンフリクトした時に、 Bundler が使っている PubGrubというアルゴリズムが、早々に依存関係の解決を諦めるという挙動によるものとのことです。

今後の展望

RubyGems と Bundler の挙動の違いを揃えるために、Resolver Engine が異なっていたり、その後の Resolver の処理が異なっているものを統合していく取り組みをされているそうです。 また、依存関係の解決が遅い問題についても、今後も取り組んでいかれるそうです。

感想

RubyGems や Bundler の内部実装に関する興味深い発表です。今まで RubyGems と Bundler の微妙な挙動の違いをあまり意識したことがなかったので新鮮でした。今回の発表では(おそらく発表時間が途中で足りなくなってしまった都合によって)あまり触れられてませんでしたが、依存関係解決の高速化については、CI の速度向上などが期待されるため実現されるのがとても楽しみです。