Emacs24で標準となるパッケージ管理システムとその周辺まとめ


Emacs24のリリースも近づきつつある(ソース俺)今日この頃、皆様いかがお過ごしでしょうか。

私はと言いますと、4月から異動で新しい職場となりEmacsの利用頻度がガクーッとさがってしまいました。というわけで、ここ最近Emacsをいぢる機会もあまりなかったのですが、次の記事が目につきまして

It’s just same as dust ahead of a wind: el-get を使って Emacs でパッケージ管理

いやはや、これはだいぶ誤解されているぞ、と。これはいかん(何が)と思い、Emacs24のパッケージ管理システムについて書いておくことにしました。

Emacs24で標準となるパッケージ管理システムとは

Emacs24では、標準でパッケージ管理システムが同梱されます。これはpackage.elにより提供されていて、Emacs23で利用したい時は以下のpackage.elを使うと良いです。

package.el

このパッケージ管理システム、実は結構前からあったにも関わらず、全くパッとしませんでした。

これは一重にパッケージのリポジトリサイトELPAに原因があります。ELPAではパッケージを登録するのに管理者にメールで依頼、というとってもレガシーな手法をとっていて、このため登録するパッケージが全く増えなかったためです。

その間、Emacsには決定打となるパッケージ管理システムがなく、auto-installやel-getなどパッケージ管理システムが乱立することとなってしまいました。

ところが、Emacs24でpackage.elが標準のパッケージ管理システムとなることが決まってからその周辺はかなり賑やかになってきました。ELPAを補完するようなリポジトリサイトができてきたのです。以降ではそのリポジトリサイトを紹介していきます。

Marmalade

MarmaladeはELPAと違い誰でも自由にパッケージの登録ができるリポジトリサイトです。

Marmalade: Spreadable Elisp

以前の日記でもMarmaladeについては詳しく書きました。

Marmaladeはお手軽感が素敵なEmacs Lispのリポジトリサイト
elispリポジトリサイト、Marmaladeの新着情報をRSS化した

Marmaladeの良いところは何といっても誰でも気軽に登録ができるというところですが、他もいろいろとメリットがあります。

例えば、ヘッダー部分に記述することによって、パッケージ間の依存関係も整理することができます。また、Marmalde自体のソースコードも公開されているため、作ろうと思えば、誰でもオレオレMarmaladeを作ることができます。

MELPA

Marmaladeは、確かにお手軽ではあったのですが問題点もありました。バージョン番号などパッケージに必要な情報はEmacsで慣習的に使われるコメントヘッダーからもってくるのですが、この部分が適切に書かれていないと登録することができませんでした。

また、パッケージをアップデートする時は、新しいバージョンをMarmaladeに登録し直す必要があり、開発者にはちょっとばかり面倒でした。

この点をel-getはスマートに解決しています。リポジトリはパッケージのソースコードリポジトリ自体となっており、そのVCSにコミットすることでパッケージもアップデートされることになります。そして、MELPAはel-getのこの特徴をうまく利用したリポジトリといえます。

MELPA

MELPAは、el-get同様パッケージのvcsが登録されていて、コミットされた日付がバージョン番号となります。そのため、MELPAに登録されればパッケージ更新のためにソースコードを改変する必要もありませんし、コミットすることでリポジトリのバージョンも自動的に更新されます。

また、MELPAに登録されているパッケージ自体もel-getライクなrecipeで管理されています。

melpa/recipes at 2253142c4c3c2d771607063b967284b91e7af079 · milkypostman/melpa

というわけで、登録してもらいたいパッケージがあればrecipeを作ってpull reqすると良いです。私も常用しているパッケージをいくつか追加してpull reqしたら、即マージしてもらえました。

Re: Emacs でパッケージ管理

アップデート用のコマンドがありません

最新のpackage.elではすでに実装されています。また、過去のバージョンを残すことでダウングレートすることもできます。

elispの側から一定の方法に則って登録してあげる必要がありますので

MElPAではelispを改変する必要はありません。el-get同様recipeを追加するだけです。

膨大な過去資産が含まれる emacswiki を直接利用できません。

同じくMElPAでは、Emacs wikiのパッケージを登録することができます。

package.elで良いんではないでしょうか

というわけで、今のpackage.elとel-getを比較するとだいたい同様のことはできてしまいます。強いてあげればel-getのafter相当の機能がpackage.elにはありませんが、その辺りはeval-after-loadなりhookシステムを使えば、柔軟に設定できるので、個人的にはあまり魅力的ではありません。

むしろ、package.elには 依存関係も記述できる、インストール用のUIがある、何より 標準(予定)であるというメリットがあります。

てことで、パッケージ管理システムはpackage.elで十分なんではないかなーと思っています。

2012-04-28 追記

el-getについてコメントいただいたので修正しました。

  • Shigenobu Nishikawa

    上の方で紹介頂いたブログのものです。いつもお世話になっている elisp 作者の方に言及いただき嬉しいです。
    package.el、だいぶ 進化していたんですね。特にMELPAの特徴には誤解がありました。
    el-get でも依存関係の記述、インストール用UI はあるのですが、標準、というのはとてつもなく強力ですね。
    MELPAの方もこれから調べていきたいと思います!

    • myuhe

      コメントありがとうございます!!
      el-getの理解がだいぶ深まりました。かなり細かく設定できるんですね。人気の理由がよくわかりました。

  • tkf

    こんにちは! el-get ユーザーなのでその特徴と思われるものを書いてみます。

     (1) autoload や auto-mode-alist を設定したりなど、どのユーザーもこの設定はするであろうという設定がレシピに組み込まれているので、ユーザー側の設定が減らせる。もちろんその設定を無効にすることも可能です。パッケージ情報以上の集合知がel-getのレシピには含まれていると思います。
    (2) リビジョン番号・タグ・ブランチ名などで使いたいバージョンを指定できる。
    (3) 自分でレシピが書けるので、サーバーに反映されるのをまつ必要がない。
    (4) パッケージのリポジトリurlを手元で書き換えられるので、 pull request を送って反映されない間は自分のリポジトリにあるパッケージを使う、みたいなことが出来る。

    逆に不満なのは全部リポジトリをひっぱって来るんで .emacs.d 以下がひたすら容量食うってことですかね。org-modeとかがやばいです。 shallow オプション使ったりとか方法はありますが…。

    MELPA 使ったことないので、それMELPAでも出来るよ!ってのがあれば教えてください。あと、 el-get からMarmalade 使えるので、 MELPA も同じように el-get から使えるんじゃないかって思います。

    • myuhe

      いつもありがとうございます。

      package.elはvcsの使用を前提としていないので、バージョン戻したりとかブランチ渡り歩いたりとかはできないですね。

      そのぶん、vcsの管理ファイルで肥大化しない、とかgitとかhgとか使えない環境でも使えるとかのメリットはあると思います。

      なので、recipe相当をサーバ側にお願いするというMELPAのアイデアは結構良いんではないかなーと思ってます。
      うちの例だとproxyがらみでel-getがうまく使えないことがあり、そういう時にpackage.elは重宝しますです。

      結局、el-getとpackage.elの両方を使うと幸せになれそうな気がしてきました。

      使いわけとしては、単一のファイルで構成されていて、わざわざcloneする必要もなさそうなものはpackage.el、ESSとかMewなどでかくてmakeinfoなど外部コマンドに依存するパッケージはel-getで管理することになりそうです。