2023-02-22 - asdf の rust clone である rtx の感触がとても良い

[kachick]

大体の依存性管理を Nix で行うようになった。 8割方のユースケースがラクラク完了でとても重宝しているんだけど、たまに引っかかる

• macos で動かそうとすると、 macos の version が上がった時に吹っ飛んでしまい、再インストールも若干面倒だった。(手動でポチポチあれこれアンインストールしないと再インストールが完了しない) macOS updates often break nix installation (updates replace path-hooks on multi-user install) NixOS/nix#3616
• macos 限定なのか clang 周りのハンドリングが謎な感じになって ruby の build が出来てない Cant build ruby 3.2.1 in darwin x86 dotfiles#151
• unstable なのを指して home-manager 使っているからなのか、macos だと zelliji がデフォルトの親切表示では動かなくなった Updating zellij always caused broken behavior if no cache cleaning was done. dotfiles#145
• 自分が nix 初心者すぎるからな事もあってか、このツールに関してはアップデートをすぐに反映させたいなとか、細かいパッチバージョン単位で言語切り替えたいなが難しい
• 初回のビルドに時間がかかるし、cache を使ってシングルバイナリ系だけを入れたとしても GitHub Actions でそれなりの起動時間が掛かる

バグっぽい物に関しては大体 macos で引っかかるので、そもそも macos では必ず lima に入ってから使えば当面は凌げるのかなー。今メイン機としては使ってないし
しかし細分化されたバージョンスイッチに関しては仕様の話だと思うので、 https://github.com/bobvanderlinden/nixpkgs-ruby みたいなのをユースケース毎に個別に探さないといけないとなるとちょっと厄介なのでは。開発中バージョンのビルドとかも、最近は全然してないけどたまにやりたくなって出来ないとちょっと困る・・・
ビルド時間に関してはそもそもプロジェクトのコンパイルとかテストにそれなりの時間がかかるなら1分程度の増減は気にならないかもだけど、それまで5秒とかで終わってた物から見ると長く感じる
asdf とやっぱり併用かな～

と思ってた時に良さげなのを見つけた。 https://github.com/jdxcode/rtx 最近流行りの？ rust で高機能なシングルバイナリ系で、 asdf の クローンを作ったという物みたい。
asdf 仕様で書かれた .tool-versions をそのままロードしつつ、asdf 向けに書かれた plugins をそのまま流用しながら、再設計されたコマンド体系で使わせてくれるらしい。実際使ってみるとかなり快適・・・ 個人的には rtx exec を使うと、rtx 経由でバージョン指定しながら対象ツールを使えるという機能が嬉しかった。メインではなくサブで asdf を使おうとしてる状態だと、これぐらいのノリで叩けるのが程よいかも

github actions に関しては作成中っぽかったので自前でゴリゴリ書いてたんだけど、https://github.com/asdf-vm/actions の asdf-vm/actions/install 相当の物を丁度完成してくれたらしく、 乗り換えに不安が無さそうな状態に kachick/dotfiles#141 (comment)
plugin test に関しても、組み合わせればなんとでもなりそうだなー

[kachick]

jdx/mise@e5897d0

mise とかいう名前に変わってた
nix やら action やら rename が必要そうで、若干面倒なんだけど相変わらず単に asdf クローンとして使える状態なのかがちょっと気になっている。
メインはあくまでnixにしているので、どっちかというとasdf資産がそのまま使えるというところにサブとしての魅力を感じていたので・・・

[kachick]

今は asdf でも mise でもなく Nix を9割の用途に使っている。ワンバイナリではなく nix も package 無くて asdf plugin はあるみたいなごく一部の用途で便利だから mise はいつでも使えるようにしているんだけど、とはいえ 過去に作った plugin の #198 とか3つぐらいはもう自分で使う機会も殆ど無くなった。そもそも nixpkgs のカバー範囲は基本的にasdfより広いのでこういう用途はあんま発生しない。過去に出たのは crystalline ももうマージされたし、podman (あるけど動かない)ぐらいかなー。しかも podman はgoでバイナリ配布形態だし別に管理ソフト無くてもなんとかなりはする
ということでリポジトリの移譲をしたいんだけど、 asdf-community は移したところで他の人があまりメンテしてくれる感無いのと orgなのに寄付対象が個人になってて??? https://github.com/asdf-community/.github/blob/73da4fadcaf76487eba63d6a69b62b54afc621a1/FUNDING.yml
全体的に asdf-vm 側は個々のプラグインにあんま関与したくないというスタンスなので産まれたorgっぽいんだけど、移す事で幸せになれるのか謎

もう一個の方法が https://github.com/mise-plugins で、こっちは逆にガチガチに固める方向で一度移したらリポジトリのコミット権すら剥奪される。
まぁその理由はわかるしそんぐらい固く管理されてるほうが使う方は幸せだろうというのと、asdf本家はもうずっとローカルで使っておらず使うにしてもmiseだからこっちに移すほうが良いのかもしれない

どちらにせよ、今はプラグイン側でなるべく両対応させようとしてるけれど片方に移すともう片方に対する互換性維持みたいなのがいずれ捨てられるだろうというのがうーむだ
一度 asdf-plugins に shortname 登録してもらったものを、リポジトリ owner 変えるだけなら兎も角動かなくなったから削りますとすると過去の .tool-versions が・・・
みたいな気にはなるけど、まーその辺り気にしても仕方ない気はする
尚 asdf-plugins に mise-plugins のリポジトリが一個だけ登録されては居る

[kachick]

Development will still need to be performed by community plugin authors via reviewed PRs.

https://github.com/mise-plugins/.github/blob/3e9352880e88fe2962a412b486ee1f0a9e65523a/profile/README.md?plain=1#L42-L43

コミット権は奪うけど、必要な更新PRは君たちが引き続き作り続けなさいという感じだとすると、引き渡す側のメリットは別にないような気もする・・・

[kachick]

https://github.com/orgs/mise-plugins/discussions/13

Done! ✅

asdf-plugins と renovate の登録名に関しても更新PRは送っておいたので、asdf関係の話をこれで忘れることが出来る・・・

とはならず、nixpkgs の podman が nixos 以外では動かないのに macos以外？は podman-remote を入れてくれないのでこの部分だけ(とはいうものの割とクリティカルな部分で)は使っているのだ・・・

https://github.com/kachick/dotfiles/blob/c283fdb1e6e5a49d8d2b9b5a641c04d462870110/home-manager/homemade.nix#L94-L103

=> renovatebot/renovate@37b316f

[kachick]

後はツール本家がインストーラーを用意していない時にサクッと github actions で prebuilt binary をインストールしやすいということで、オーナーシップを手放した後で https://github.com/mise-plugins/asdf-yamlfmt をよく使う様になってきた。yamlfmt 本家だと go install でのやり方が紹介されているけど action でそれ使うと13秒かかるインストールが1秒ぐらいで済むようになるのと、そもそも yamlfmt は go 1.20 以上に上げたとき謎のバグ報告が相次いだから 1.8 にビルドを固定しているという事情があるので pre built のが一番安心感あるといえなくもない(nixpkgs側のgoはぽんぽんあがってしまっている)

[kachick]

GitHub の仕組み上なのかリポジトリ移譲したあとも related レベルだと CI落ちのアラートとか上がってきて厄介なので完全通知オフにしないとだめだった。
そして直すようなPRを送っても数ヶ月反応がないので 引き渡す側のメリットは別にない の杞憂が割と当たってしまった感。生殺与奪の権~

最近増えたエラーは luizm/asdf-shellcheck@a2a1c48 で shellcheck 側のプラグイン側でパッチを取り入れてもらえたけれど、こんな感じの状態が続くと何も良いことが無いので完全通知オフの方が良さそう・・・

そういえば asdf の方はメンテナの方が golang で書き直してるから他を放置してる的な事書いてたけど、miseがある状態でasdf側を別言語でリライトするメリットがあんまよくわかってはいない