Closed kachick closed 1 year ago
https://github.com/jdx/mise/commit/e5897d097c1f90c8a263f0e685a56908e2c023da
mise とかいう名前に変わってた nix やら action やら rename が必要そうで、若干面倒なんだけど相変わらず単に asdf クローンとして使える状態なのかがちょっと気になっている。 メインはあくまでnixにしているので、どっちかというとasdf資産がそのまま使えるというところにサブとしての魅力を感じていたので・・・
今は asdf でも mise でもなく Nix を9割の用途に使っている。ワンバイナリではなく nix も package 無くて asdf plugin はあるみたいなごく一部の用途で便利だから mise はいつでも使えるようにしているんだけど、とはいえ 過去に作った plugin の https://github.com/kachick/times_kachick/issues/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 のリポジトリが一個だけ登録されては居る
Development will still need to be performed by community plugin authors via reviewed PRs.
コミット権は奪うけど、必要な更新PRは君たちが引き続き作り続けなさいという感じだとすると、引き渡す側のメリットは別にないような気もする・・・
https://github.com/orgs/mise-plugins/discussions/13
Done! ✅
asdf-plugins と renovate の登録名に関しても更新PRは送っておいたので、asdf関係の話をこれで忘れることが出来る・・・
とはならず、nixpkgs の podman が nixos 以外では動かないのに macos以外?は podman-remote を入れてくれないのでこの部分だけ(とはいうものの割とクリティカルな部分で)は使っているのだ・・・
=> https://github.com/renovatebot/renovate/commit/37b316f337e8f8d291af3c865f1146df5911f9a4
後はツール本家がインストーラーを用意していない時にサクッと 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はぽんぽんあがってしまっている)
大体の依存性管理を Nix で行うようになった。 8割方のユースケースがラクラク完了でとても重宝しているんだけど、たまに引っかかる
バグっぽい物に関しては大体 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 相当の物を丁度完成してくれたらしく、 乗り換えに不安が無さそうな状態に https://github.com/kachick/dotfiles/pull/141#discussion_r1113865715 plugin test に関しても、組み合わせればなんとでもなりそうだなー