use-package.elからleaf.elに移行した

この度、use-package.elからleaf.elに移行した。
どうして移行したのかや、その時の調査した周辺技術や、移行に関する知見を、せっかくだしメモしておく。

なお、内容を書くにあたって、Emacs 26.3とGitHubレポジトリのコードで調査している。

背景

Emacsのパッケージとその設定を、以下のように管理している。

• dotfiles全般の一部としてGitHubにてGit管理している
• package.elを使っている
  • Emacs24から標準だしね
• use-package.elを使っている
  • メジャーなパッケージ設定を構造的に管理するパッケージ
  • 今年の春くらいに導入したばかり
  • パッケージ設定が構造的に書けて最高の気持ち
• 野良パッケージを、git addやgit submodule addを使って管理している
  • 野良パッケージはpackage.elの管理外のパッケージを指す
  • MELPAに登録されてないものや既存パッケージを一部変更したものがある
    • 例えば、手元のsml-modeにSML#のキーワードを追加している

問題点

• GitHubのbranchやforkなどの野良パッケージを、Emacs Lispでキレイに扱いたい
  • use-package.elにこの機能はない
  • この解決のためにgit submoduleを使っているが、
    submoduleの初期化や更新など操作がフクザツなため止めたい
• use-package.elを導入したばかりなので、コストは低く解決したい

結論

• use-package.elとその拡張を使うのをやめた
  • 今回の調査では、満足できるuse-package.elの拡張が見つからなかった
• use-package.elからleaf.elへ移行した
  • コストはそこそこ高かったが、完全移行してよかった点が多かった
  • leaf.elはいいぞ
• 一部のgit submoduleは止めれていない
  • 今回は議論しないが、snippetのレポジトリをうまく扱う方法を考えていない

トライしたメモ

use-package.elはキーワードを拡張できるため、多数の統合拡張がある。
そこで、use-package.elの拡張を初めに調査した。
また、use-package.el以外にも良いパッケージ設定管理ツールがないか調査した。
特に、use-package.elとキーワードが似通っているとなお良い。

ざっくり調査すると以下の3つを見つけ、それぞれ試すことにした。

• use-package.el + quelpa.el
• use-package.el + straight.el
• leaf.el

なお、パッケージ管理のバックエンドとしてはpackage.elは使うことにし、
これ以外のバックエンドの調査はしていない。

use-package.el + quelpa.el

Quelpaはパッケージのビルド・インストールを行うツールである。

これ自身にはuse-package.elのようなパッケージ設定管理の機能はない。
代わりに、quelpa-use-packageというインテグレーションが用意されている。

良かった

• use-package.elとのインテグレーションがあるため移行コストが低い
  • use-package節内で:quelpaキーワードが使えるようになる
• :quelpaキーワードを使って、GitHubのbranchが指定できる
• package.elのパッケージ状態を認識してくれる
  • 依存関係などがいい感じに解決される
  • Quelpaでインストールするとpackage.elのインストールマークをつけてくれる
  • quelpa/buildでビルドしてelpaにコピーしているようだった

悪かった

• 存在しないパッケージを(quelpa PACKAGE ...)で指定してもエラーが出ない
  • まじか？？？
  • :quelpaだとさすがにuse-package.elがエラーを出してくれる
• 開発が終了している

use-package.el + straight.el

straight.elは次世代の純粋関数型のパッケージマネージャらしい。
なお、どの辺が純粋関数型なのかはよくわからなかった。
他のパッケージマネージャとの比較を、しっかりしているのに好感が持てた。

これも自身にはパッケージ設定管理の機能ははない。
代わりに、use-package.elとのインテグレーションを持っている。

良かった

• use-package.elとのインテグレーションがあるため移行コストが低い
  • use-package節内で:straightキーワードが使えるようになる
• :straightキーワードでGitHubのbranchやforkの指定ができる
  • 機能としてもドキュメントとしても便利
• :straightキーワードを使うと、デフォルトでEmacsMirrorのパッケージも
  探索してくれて便利だった

悪かった

• package.elとの相性が悪い
  • package.elのインストール状態を認識せず、
    straight.elは独自で依存関係も込みでインストールする
  • 結果、依存関係のパッケージが大量に重複してインストールされる

leaf.el

leaf.elはYet Another use-packageで、パッケージ設定管理のパッケージの1つ。
Emacs Advent Calendarにも多数寄稿している@conao3さんが開発している。
昨年12月にバージョン1.0.0が出た比較的新しいパッケージ。

何度かQiita記事でも目にしており、気になっていた。
YA use-package.elということで、移行コストを低く抑えつつ、
よりよい機能が得られるのではと思って試した。

良かった

• package.elのパッケージ状態を認識してくれる
  • Quelpaと同上、というかpackage.elをバックエンドとして使っている？
• GitHubのbranchが指定できる
  • el-get.elとのインテグレーションがあり、:el-getを使い実現できる
• leaf節で:el-getを使ってインストールすると依存パッケージを解決しない
  • そもそもpackage.elの管理外のものを導入しようとしているため、
    依存関係などを自分で管理するのは妥当と思える
  • leaf節をネストして書けるため、依存関係も書きやすい
  • 導入元がpackage.elとel-get.elとで違うものを、ちゃんと分離して管理できる
• leaf節をネストして書けるため、関連する設定をまとめられる
  • 例えば、companyの設定の中に、company-**の設定を書いておける
  • use-package.elでもできないことはないが、推奨されていない
• 移行しただけでEmacsの起動時間が半分になった
  • use-package.elでは:defer tで遅延読み込みの指定がいるが、
    leaf.elではデフォルトで遅延読み込みなのも効いていそう
  • use-package.elは起動時間の統計をとるなどリッチな機能を持っており、
    そもそも遅いのも効いていそう
  • 詳細な原因調査はしていない
  • な に も し て な い の に Emacs が は や く な り ま し た

悪かった

• ネストしたleaf節がつくるツリー構造が、パッケージの関係性に合わないものがあった
  • あるモードの設定を、グローバルモードとメジャーモードのどちらに
    まとめるか問題
  • 例えば、company-jediはpython-modeでcompanyの補完を提供するが、
    機能としてcompanyにまとめるべきか、modeとしてpythonにまとめるべきか
  • 好きにすればいいと思った、書ける自由度があるのは良い
• use-package.elと書き方違いが多少あり、まあまあ移行コストがかかった
  • 1,000行ほどの元のelファイルに対して、500行ほどのdiffがあった

leaf.el移行での変更点や感じたこと

• キーワード名が一部違うことがある
  • :defer tに対応するのは:leaf-defer tなど
• :customの引数のデータ構造と許される値が違う
  • :customの引数がリストではなくドットペア
  • :custom (x . (1+ a))のような未評価部は許されていない
    • defvar b (1+ a)とかして:custom (x . b)とする
• デフォルトでパッケージがrequireされない
  • requireが必要なパッケージには:require tをつける
• 遅延読み込みがデフォルトとなっている
• :bindでのmap名の書き方が違う
  • (:map xxx-mode-map ...)を(:xxx-mode-map ...)にする