Go Modulesの仕組み Bundler(Ruby)との比較を添えて

Fukuoka.go#21
https://fukuokago.connpass.com/event/344467/
での
『Go Modulesの仕組み Bundler(Ruby)との比較を添えて』
です！

Transcript

1. Go Modulesの仕組み ~Bundler(Ruby)との⽐較を添えて~ 1 どすこい Fukuoka.go#21
2. 2 GMOペパボ Webエンジニア どすこい Daisuke Takeda k1low⽒の弟⼦に習って(=孫弟⼦)、 Goが好きになっちゃったエンジニア 配属先はRails/PHPですが、 そこでもGo⾰命を起こします！！ Goコミュニティに参加してくぞ〜！ X: @doskoi64
3. PythonやRubyで、 考えなしにパッケージを⼊れると 依存関係解消が失敗することがある... マイナーバージョンアップでも 壊れることある.... ある⽇ イントロダクション 3
4. Railsの場合 イントロダクション 4 Railsガイド https://railsguides.jp/maintenance_policy.html 破壊的変更するんだ...?🤔
5. ⼀⽅で Goではあんまり気にしたことないなぁ なんで気にしなくていいんだろ...？ ある⽇ イントロダクション 5
6. Go 1.11より イントロダクション 6 https://github.com/golang/go/issues/24301
7. Go 1.11より イントロダクション 7
8. Go 1.11より イントロダクション 8 (前略)、Bundler/Cargo/Depのアプローチの詳 細と、それをGoに組み込むことの意味をより深 く理解し、(中略)、いくつかの細部がGoには適 していないと次第に感じるようになりました。 最初は同じ感じだったんだ？ 何が違うんだ？
9. 9 今⽇話すこと • Go Modulesの依存解決の仕組み • Bundler(Ruby)との⽐較 今⽇話さないこと • Go Modulesでどこがどう動いてるのか • Bundlerがどこでどう動いてるのか • これらの歴史的な経緯
10. Go Modulesの仕組み Go Modulesとは • Go 1.11から導⼊ • モジュール:複数のパッケージをまとめてリリース/バージョン管理/配布するための 単位。GitHubやモジュールプロキシサーバからダウンロードが可能 • モジュールパスによって⼀意に識別してgo.modで宣⾔ • go.sumにモジュールのハッシュが保持され、ダウンロードしたモジュールの内容が 相違ないかチェック 10 https://go.googlesource.com/proposal/+/master/ design/24301-versioned-go.md ref: Go Modules Reference (https://go.dev/ref/mod)
11. 11 Go Modulesの仕組み https://github.com/golang/go/issues/24301 昔はdep, glideなど外部 ツールを⽤いていた。 標準化しようぜ！
12. Go Modulesの仕組み • go.modに列挙された直接依存から、それぞれが要求す る他の依存(間接依存)を再帰的に集めてビルドリストを 作成 • 各モジュールでは必要最低限のバージョンを宣⾔ • これを⽤いてMinimal Version Selection (MVS)で最終 的な依存バージョンを決定 依存解決 12
13. Go Modulesの仕組み • go.modに記載された直接依存が必要とする依存(間接依 存)を再帰的に収集 ◦ 各モジュールは必要最低限なバージョンを指定するた め、すべての依存先から集まった最⼩の要件の中で、 最⼤値となるバージョンが選ばれる ◦ module Aではhoge v1.2.3が、module Bでは hoge v1.5.0が要求される時はv1.5.0を採⽤ Minimal Version Selection (MVS) 13
14. Go Modulesの仕組み module Aでhoge v1.2.3が、 module Bでhoge v1.5.0が使われてる→v1.5.0を採⽤ そぼぎ(素朴な疑問) 14 けど、なんでmodule Aでは v1.5.0で動く前提なの？
15. Go Modulesの仕組み module Aでhoge v1.2.3が、 module Bでhoge v1.5.0が使われてる→v1.5.0を採⽤ そぼぎ(素朴な疑問) 15 けど、なんでmodule Aでは v1.5.0で動く前提なの？ Semantic Versioningのルールより モジュールパスが同じなら後⽅互換がある！ (逆に⾔えばこれが前提のシステム)
16. Go Modulesの仕組み そぼぎ(素朴な疑問) 16 じゃあmodule Aではv1.2.3が、module Bではv2.1.0が 使われてる時、v2.1.0を採⽤するの？(A壊れない？)
17. Go Modulesの仕組み そぼぎ(素朴な疑問) 17 じゃあmodule Aではv1.2.3が、module Bではv2.1.0が 使われてる時、v2.1.0を採⽤するの？(A壊れない？) モジュールパスが異なるv1, v2両⽅採⽤する！ ex) gihub.com/oklog/ulidとgithub.com/oklog/ulid/v2 別モジュールとして扱われるので、 v1.2.3とv2.1.0の両⽅をimportすることで 対処できる
18. Go Modulesの仕組み 詳しくはGO Conference2024ののびしーさんの発表があります！ 18 https://gocon.jp/2024/sessions/13/
19. Rubyとの⽐較 • gem の依存関係とバージョンを管理するための ツール • Gemfileで任意にgemのバージョン を指定できる ◦ = のほかに、<=, >などで⼤⼩関係で指定できる Bundler 19
20. Rubyとの⽐較 Gemfileに指定された制約を解析し、 全ての制約を満たすバージョンの  組み合わせを探す ⼤変らしい(NP完全) https://arxiv.org/pdf/2011.07851 (⾼速な解法がないとも⾔えるかも) Bundlerの依存解決アルゴリズム 20
21. Rubyとの⽐較 • Aでは ◦ Cについて”>= 1.0, < 3.0” • Bでは ◦ Cについて”>= 3.0, < 3.5” Bundlerが困る時: 解がないとき 21 最適なバージョンがない場合が発⽣しうる ※ (補⾜) 別gemとして別バージョンを利⽤する⽅法はあるらしい けどGo Modulesはシンプルで⼀意に決まります → 解なし...
22. ⽭盾の例 • Aでは ◦ Cについて”>= 1.0, < 3.0” • Bでは ◦ Cについて”>= 3.0, < 3.5” Rubyとの⽐較 なんでGoだとこうならないの？ 22 Goでは、C v1.0とC v3.0を 別モジュールとしてimportできる
23. ⽭盾の例2 • Aでは ◦ Cについて”>= 1.0, < 1.5” • Bでは ◦ Cについて”>= 1.6, < 2.0” Rubyとの⽐較 なんでGoだとこうならないの？ 23
24. ⽭盾の例2 • Aでは ◦ Cについて”>= 1.0, < 1.5” • Bでは ◦ Cについて”>= 1.6, < 2.0” Rubyとの⽐較 なんでGoだとこうならないの？ 24 Semantic Versioningの後⽅互換の前提があるので マイナーバージョンの上限を指定しないので起こらない → v1.6になる
25. まとめ Go ModulesはSemantiv Versioning を前提に依存関係解消をしている 任意にバージョンを指定できる⾔語の 場合、最適なバージョンをソルバーが 解く必要がある Go Modulesはルールによってシンプル さを獲得した具体例かもしれない 25 今⽇話したこと
26. 26 Let’s Go