トップ «前の日記(2023/02/21 (火) ) 最新次の日記(2023/02/23 (木) 天皇誕生日)» 編集

HsbtDiary

2023/02/22 (水) [長年日記]

■ Ruby CI を importmap-rails/dartsass-rails 対応した

昨日に続いて Ruby CI を propshaft は残したまま、jsbundling-rails と cssbundling-rails を使わない、つまり yarn などには頼らないようにしてみた。

相変わらず元となるコードはめちゃくちゃ小さいので、変更による影響はほとんどないけど、DHH がこうしたいのだなというのを把握しながら、yarn であるとか sprockets 的な物を剥がすのがちょっと時間かかった。これ、sprockets とか webpacker な状態の人は適当に触ってみたほうが良さそう。

ひとまず、jsbundling-rails の方は雑に importmap-rails にできるので、単に入れた上で importmap.rb に向けてバンバン pin 打って追加する、で良さそうなものの cssbundling-rails の方はこなれてない、というか、具体的には bootstrap などを入れたいんだよなあというあたりでは node_modules から持ってくる、というような機構は用意されてないので自分で bootstrap.min.css などを持ってきて vendor/assets/stylesheets に入れる、みたいなことをやらないとダメぽいのがちょっとだるかった。

ようは dartsass-rails (+ propshaft) は単純に sass/scss のコンパイルしか提供しておらず、自分たちが使おうとしている css の管理まではやらないようだった。bootstrap の gem などを入れればできると言えばできるけど、sprockets が復活してしまうので今回は使わないことにした。

まあ、css は bootstrap なら上の方法でいいだろうし、tailwind なら tailwindcss-rails を使いましょう、終わり。なんだろうなあ。そもそも CSS フレームワークを使いつつも Rails サイドで管理したいという方が少数派なのだろう。

大体仕組みはわかったのだが、jsbundling-rails/cssbundling-rails/importmap-rails/dartsass-rails あたりの組み合わせをどうするのが良いのか、という勘所をつけるにはもうちょっと大きいアプリがないと難しそうだなあ。

■ GitHub Actions から macos-10.15 がそろそろなくなるので対応

GitHub から ruby org の下にある Actions が macos-10.15 を使ってるけど、これ 2023-3-31 に完全になくなるから対応しといて、とメールが来たのでせっせと対応した。

この辺、せっせと対応しなくても https://github.com/ruby/actions/blob/master/.github/workflows/ruby_versions.yml みたいな仕組みでいい感じになって欲しいんだよなあ。

■ debug gem の依存ライブラリが bundle install で消えてしまう現象を解決した

昨年の後半に tDiary の Rack 3 対応をやっている時に debug gem の依存である irb と reline が bundle install を実行しただけで消えてしまう現象を見かけて、その時は bundler のちょっとした変な挙動かな、くらいでスルーして rack のバージョンだけを個別にあげていたのだけど、あちこちで似たような報告が出てきた。

というわけで、何かが起きている、という予感から詳細に調べることにした。

結論としては bugs の最後に貼ってあるパッチの通りなのだが、ruby/ruby では C extension な bundled gems を make install の際にコンパイルする仕組みがあって、そのために依存ライブラリは不要となるように加工した gemspec をインストーラが使ってしまい、Ruby をインストールした直後に入っている debug gem から依存ライブラリが消えてしまった、ということだった。そのために bundle install などを実行すると、debug gem には依存ライブラリがないよね、と Gemfile.lock からも消えてしまう。辛い。

この辺は nobu マジックにより実現されている非常に複雑な仕組みなのだけど、今後のためにも理解したことを書いておく。debug gem のビルドとインストールには以下のような gemspec を扱っている。何故 3 つもあるのか、ということだけどしょうがない。

.bundle/gems/debug-1.7.1/debug.gemspec
- debug gem のオリジナルとして含まれている gemspec
.bundle/gems/debug-1.7.1/debug-1.7.1.gemspec
- debug gem のオリジナルを ruby のソースツリーに合わせて展開したファイル、具体的には git ls-files などがファイルリストになっている。C ext な bundled gems のみ生成される。
.bundle/specifications/debug-1.7.1.gemspec
- C ext の時はビルドディレクトリに作成されるファイル。debug gem をテストのためにビルドするときに用いる。なお、pure ruby な bundled gem の場合はソースディレクトリに gemspec が配置される。何故こうなっているのか。なぜ...。

さらに複雑なのだが、この消えてしまう、という症状はソースコードを展開したディレクトリでビルドを行う in-place ビルドの時のみ発生する。というのも、インストーラが gemspec を検索する順序は上記の箇条書きの下から順に2つを探すようになっていて、in-place の時は一番下の依存関係がない gemspec が採用されるが、out-place の時は見つからないので、真ん中のまともなファイルが使われる。

結局どうすればいいか、というと最初に真ん中のファイルを探索して、なかったら一番下、という順序にすれば依存ライブラリを保持した gemspec を使うので、そうなるようにしたパッチを投げておいた。

これ、調べていて自分でも複雑すぎて頭を抱えたんだけど、一時的に加工して使う gemspec は pure ruby な gemspec が配置されるディレクトリではなくて専用の場所を用意したほうがいい気がする。とりあえずパッチがバックポートされて Ruby がリリースされれば解決されるのでそれ待ちで...。

[ツッコミを入れる]