packageでの管理方法

[sabottenda]

packageを使っている時に同じ環境を再構築したい場合はどのように管理しているでしょうか？
1つはpackageでインストールしたパッケージもgitなどで管理するというのもありますが、できればpackageでいれたものはVCSには入れたくないと思っています。

https://gist.github.com/sabottenda/5011883
今はpackageでインストールするもののリストを列挙しておいて、init-loaderで最初にインストールされてないものをチェックするようにしています。
他にスマートな方法があれば教えて頂きたいです。

[syohex]

packge.elだとそんな感じにしかならないと思います。

ただ package.elだと古いものでもインストールしていると判定されているため、
厳密に同じ環境かと言われると難しいものがあるかと思います。

極力最新のものを使って合わせるということで、el-getの方が的確かも
しれません。

[tarao]

僕の場合は、最初のうちはインストールするもののリストを列挙する方法でやっていたのですが、package.elだけでなくel-getも使うことになってしまったので、いまではel-getに一本化しています。

ただ、el-getを公式の使い方通りに使うと、パッケージをインストールするための指定((el-get 'sync PACKAGE))と、そのパッケージに関する設定が別ファイルになってしまうのが気に入らなかったので、bundle.elというラッパを自分で作って使っています。

[sabottenda]

@syohex
package-menu-mark-upgradesで更新のものをマークする関数はあるみたいなので、実装すれば自動更新も実現できそうですが、デフォルトではなさそうですね。

@tarao
やはりこだわるとel-get使って管理になりそうですね。
bundle.elはシンプルなので登録もしやすそうですし、一回登録すれば後の管理は楽そうですね。

個人的にはpackage.elだと一覧を適当に見て新しいものを探したりするのが気軽にできるのが良いかなと思っています。
package.elと統合でうまく管理できたら良いのですが、どうしてもネックになるのがemacswikiなどのコードになりますね。

ちなみに最初に示したコードに近いパッケージとして save-packages がありました。
あとは carton などがありますが、こちら試された方はいますか？

[syohex]

@sabottenda cartonはどうなんですかね ? あくまでパッケージレベルでの依存関係の解決という
感じなので、全体をそれで管理というのには向いているんですかね ? テストでは使えそうですが。

[sabottenda]

@syohex rubyのbundlerみたいなものだとすると割とありなのかなと思いました。必要なパッケージを指定するとそれに依存するものも自動で入るような。

[syohex]

@sabottenda bundler自体よくわかっていないんですが、あの手のやつのいいところは
プロジェクト単位というかソースツリー単位で、すべてを閉じれることだと思うのですが、
Emacsの場合、いざ使おうとすると結局グローバルにインストールするのと変わらないと
思うので、どうなんだろう、って思っています。

[tkf]

user-emacs-directory を利用すれば複数の .emacs.d を持てるので、そういう使い方していれば carton も役に立つんじゃないですかね。 https://github.com/tarsius/fake-emacsd とか使えば ~/.emacs.d を直書きしている elisp も試せますし。

Carton のラッパーで https://github.com/rdallasgray/pallet みたいなものもあるみたいです。使ったことないですがインストール済みパッケージを Carton ファイルに自動的に dump してくれるみたいですね。

[syohex]

なるほど、みなさんいろいろ考えられているんですね。
普段そういうのを全く使わないので、思いもつきませんでした。

[syohex]

どうでもいいかもしれないですが、Cartonの問題は Perlの bundler的なものの名前も
cartonということですかね。今時は Rubyや Python
やらで Perlやっている人は少ないんでしょうけど、コマンド名まで同じというのは
Perl使いからすると若干困りますね(ecartonという aliasをつけて対応しています)

Perl版の方が数年早く作られているし、なんとかならなかったのかとは思いますね。

[kiwanami]

cartonってどこかで見た気がすると思ったら、そういうことでしたか。

[syohex]

以下は単純過ぎるまとめですが、現状何を使うにしても一長一短があると
思いますので、それらのまとめを作るということで良いでしょうか ?

package.el

メリット

• Emacs24移行であれば標準添付
• el-getと比べると簡単

デメリット

• インストール以外のことを行えない(makeとかその他もろもろの処理)
• 各種 ELPAサイトに登録されていなければ、インストールが困難(不可能ではない)

el-get

メリット

• インストール前、後に任意の処理を追加できる
• 本体にレシピがなくても自分で書ける

デメリット

• package.elと比べると複雑
• 公式ではない

[sabottenda]

そうですね。closeするタイミングが難しいと思っていたところなのでまとめて終わりにしたいですね。
おおまかにはpackage.elとel-getの2つを使った管理方法があって、それぞれのラッパーとしてsave-packageやcartonやbundleがあるというところでしょうか。

[tkf]

ちょっと知ってることだけフォローしてみます。 el-get はいくつかの backend があります。多分一般的な印象だと git repository から直接インストール、みたいな感じかもしれませんが、 package.el もひとつの backend です[1]。デフォルトだと el-get をインストールしたら marmalade からもダウンロード可能な状態になるなど、その辺よしなにやってくれるはずです。なので、 el-get vs package.el な視点は、 el-get が package.el を内包している時点で違う気がするなあと感じます。だから、正確に区分すると el-get も package.el のラッパー(と他の機能多数)と言えると思います。まあ el-get の UI だけ見ると backend は見えないので意味のある言及かは分かりませんが。

[1] 他に emacswiki、VCS色々、システムのパッケージマネージャ(apt-get/pacman)など。

[syohex]

参考になります。より高度に使いたい場合は el-getという視点がいいですかね。

[Shougo]

私が調べてみた感じだと、el-getはWindows上での使用に問題があるようです。インストールに苦労している情報をよく見ます。パッケージマネージャは基本的にどこでも動作するのが理想ですが……。

[sabottenda]

@tkf
el-getは様々なソースからインストールできるということでその一つがELPAだと思っているのですが、
el-getがpackage.elを内包しているというのは、el-get経由でELPAのパッケージをインストールした場合にpackage.elのUIで見たときにもインストールされている状態になるということになるのでしょうか？

[tkf]

@Shougo 作者曰く windows は first class citizen だそうなので windows を蔑ろにしてるわけじゃないはずですが、多分 dev の中に windows user がいないんでしょうね。。。 windows 周りのバグの修正は遅いです。

@sabottenda 見たこと無かったですが、 package-list-packages みたらちゃんと installed って出てました。

[Shougo]

@Shougo 作者曰く windows は first class citizen だそうなので windows を蔑ろにしてるわけじゃないはずですが、多分 dev の中に windows user がいないんでしょうね。。。 windows 周りのバグの修正は遅いです。

ふーむ。それは残念ですね。

[sabottenda]

@tkf なるほど。 そうなると確かに上位互換みたいになりますね。

ひとまず今まで出た情報から特徴をまとめてみました。
曖昧なところや間違ってるところは補足して頂けるとありがたいです。
ちなみにここでいう状態管理というのは現状の環境と同じ構成を別環境で再現できるような機能を意味してます。

auto-install

• 以前から使われているパッケージインストーラ(非公式)
• URLがあればインストールを自動化
• パッケージの管理機能(更新,削除,状態管理)は無い

package.el

• Emacs24から標準添付
• ELPA(本家, marmalade, MELPA)にあるパッケージしか基本インストールできない(ただし不可能ではない)
• UIから比較的簡単に操作できる
• 更新削除はできるが状態管理(リストの保存, リストア)はできない
• インストール前後に任意の処理ができない

el-get

• ELPAを含むあらゆるソースを管理できる
• 標準添付ではない
• package.elよりは管理(記述)が複雑
• 更新削除も可能。状態管理は使い方次第(?)
• インストール前後に任意の処理を追加できる
• 現状 Windowsでの利用に難あり

carton

• package.elのラッパー
• パッケージ間の依存関係を記述可能
• 状態管理できる(むしろそれが主目的?)

bundle.el

• el-getのラッパー
• el-getの記述をシンプルにしたもの
• 状態管理も容易(?)

[syohex]

@sabottenda 勝手に更新しました.

package.el

• ELPAからのインストールに関する記述を更新

el-get

• ELPA以外 => ELPAを含む
• (追加) Windowsでの利用に難あり

[tkf]

状態管理というのは現状の環境と同じ構成を別環境で再現

これは、パッケージのバージョン構成も再現出来るかどうかも考えていますか? package.el がその辺りサポートしているのかどうか気になります。 melpa から開発版を落とした場合は、サーバーに過去すべてのスナップショットがあるとは考えられないので無理でしょうが、 ELPA/Marmalade に登録されているものはどうなんでしょう。

ちなみに、 el-get は VCS 系の backend ならリビジョン単位で再現可能です。 emacswiki などからファイルをそのままダウンロードする場合でも、チェックサムを記録しておいてそれと違うものがダウンロードされた場合は通知するみたいなことも出来ます。

el-getの特徴として「外部ツールのインストールが出来る」もあった方が良いかもしれません。これは「インストール前後に任意の処理を追加できる」ことに含まれるのですが、Emacsが他のプログラミング言語で書かれたツールと連携することが多いことを考えると特筆したほうが良いように思えます。例えば、 el-get に登録してある Python のツールは依存モジュールのインストールとパスの設定が自動で済むようになっています。

あと、 el-get も 4.1 (最新のリリース) から、 (el-get がロード出来ていれば) 設定ファイルを弄らなくもパッケージのインストールが出来るようになっています。この機能が package.el と比較してどこまで安定しているかどうかはちょっと良く分かりません。

el-getの便利機能はパッケージ管理からはみ出すのも含めるともっと色々あります。パッケージ事に init ファイルを分けられたり、それを自動でコンパイル出来たり、遅延読み込み出来たり...。

@myuhe さん曰く、 package.el の利点 (というか el-get の欠点) として、proxy関係でVCSサーバーに上手く繋げない場合でも使える、というものもあるようです。
http://sheephead.homelinux.org/2012/04/27/6989/

[myuhe]

呼ばれた気がしたので、ちょこっと書いてみます。

これは、パッケージのバージョン構成も再現出来るかどうかも考えていますか
? package.el がその辺りサポートしているのかどうか気になります。melpa
から開発版を落とした場合は、サーバーに過去すべてのスナップショットがあ
るとは考えられないので無理でしょうが、ELPA/Marmalade に登録されている
ものはどうなんでしょう。

ELPAについては知りませんが、Marmaladeはサーバ側にバージョンごとのキャッシュ
を保持しています。

ただ、package.elからバージョン管理ができるようなものではなく、Marmaladeに
パッケージを置いている管理者のために提供されているようです。

package.elについて言えば、ローカルにあるものは前のバージョンを残すという
ことで、素朴なバージョン管理はできますね。

el-getの特徴として「外部ツールのインストールが出来る」もあった方が良い
かもしれません。これは「インストール前後に任意の処理を追加できる」こと
に含まれるのですが、Emacsが他のプログラミング言語で書かれたツールと連
携することが多いことを考えると特筆したほうが良いように思えます。例えば、
el-get に登録してある Python のツールは依存モジュールのインストールと
パスの設定が自動で済むようになっています。

私もこれがel-getの最大のアドバンテージだと思っています。package.elだとこ
れができないので、MELPAの中の人たちもいろいろと苦労をされてますね。

あと、el-get も 4.1 (最新のリリース) から、(el-get がロード出来ていれ
ば) 設定ファイルを弄らなくもパッケージのインストールが出来るようになっ
ています。この機能が package.el と比較してどこまで安定しているかどうか
はちょっと良く分かりません。

package.elもautoloadのマジックコメントが正しくついていれば、設定ファイル
をいぢる必要はないはずです。

@myuhe さん曰く、package.el の利点 (というか el-get の欠点) として、
proxy関係でVCSサーバーに上手く繋げない場合でも使える、というものもある
ようです。

これと、@Shougo さんの言われていたWindowsへの対応がel-getの欠点だと思っ
ています。

私もmakeinfoなどの外部ツールが必要なパッケージだけをel-getでしばらく管理
していたのですが、ネットワークにセキュリティなどの理由で制限がある環境だ
と、まずVCSをまともに動かすのにかなり苦労します。

一方、package.elだとHTTPだけ話せればどうにかなるので、そのあたりがとても
楽です。

それと、VCSの利用がほぼ前提にあるel-getの場合、Windowsでの利用で問題が起
こりやすく、しかも原因が判別しにくい場合が多い気がします。

それと、el-getは複数のアップデートをかけると、いろんなとこのサーバに接続
することがあるので、頻度としてサーバの不調によるアップデートの失敗に遭遇
しやすいです。

その点、package.elだとせいぜい二つくらいのサーバにアクセスするだけなので
安定的に使えています。ただ、これはリスクが集中することでもあるので、例え
ばMELPAが落ちてたりするとどうしようもないのですが、これまでそういった事
態はあまり起きてないと思います。

こんな理由もありまして、手元でのバージョン管理はメインをpackage.el、外部
ツールが必要なものはOSのバージョン管理(うちのはArchLinuxのABSというので
す)で管理するようになりました。

こういった類のものを選択する理由は個々人の環境それぞれで違ってくるでしょ
うから、それぞれの特質をここで整理しておくのは、かなり有用ですね。

[sabottenda]

@tkf どこまで需要があるかは別として、理想的にはバージョン指定で再現できると良いですね。

あれこれ考えてるうちに @myuhe さんが丁寧に回答して頂いていますね。ありがとうございます。

package.elは発展途中で機能としては足りない部分もあるが、公式パッケージでシンプルということで扱いやすいというのがありそうですね。
el-getは高機能な反面、設定が煩雑であったりいくつか問題があったりする場合もあるというところでしょうか。

改善次第でどうなるかわからないですが、現状ではパッケージ管理といえばコレ！という決定はできないようなので各パッケージのpros/consをまとめておきたいですね。

まとめると追加でこのような感じでしょうか。

package.el

• HTTPが使えればインストールできる
• バージョン指定でインストールはできない
• 外部ツールはインストールできない(同じリポジトリのファイルなら可能)

el-get

• インストールにVCSを使える必要がある
• (一部)バージョン指定でインストールすることもできる
• 外部ツールもインストールできる
• その他様々な機能あり

[syohex]

外部ツールと読んでいいかわからないですが、MELPAについては、同一リポジトリに
あるファイルについてはレシピに記載することでインストール可能です。marmaladeも
tar.gzの形式でアップロードすればたぶん可能です。完全に外側にある Pythonスクリプトを
インストールする等のことは無理ですけど。

[sabottenda]

@syohex なるほど。だとすると大抵の場合はその方法で問題無さそうですね。

[myuhe]

el-getの利点を正確に表わすなら、外部ツールをインストールして実行できるところですかね。
ESSやemacs-w3mなどAutotools前提のものをpackage.elでインストールしようとするとサーバ側に工夫が必要ですね。

[syohex]

@sabottenda ぼちぼちまとまってきたので今までの内容をまとめたものを、ページとしてを作成して
いただけないでしょうか ? packages/package-management.mdみたいなファイル名で良いかと
思います。

リンクをどう貼るかは後でもいいので、ページを作成して pull requestしてください。
forkでなく、リモートブランチからの pull requestで良いです。以降の議論はそこで
具体的にしていきましょう。

お手数をお掛けしますが、よろしくお願いします。

[tkf]

@syohex さんのおっしゃるとおり、 package.el の形式は別に elisp 以外のファイルも含めることが出来て、 info ファイルを含めているパッケージとか結構あるみたいです。 なので、 elisp 以外のものも mermalade とかで含めるようにしておいて、 el-get でその外部ファイルの処理をする、みたいなことが出来れば、 proxy や VCS 依存の問題はすべて無くせて、 el-get の利点も受けられるだろうな、と思っています。 大量にレシピを書き換える必要がありますが...。

@myuhe

Marmaladeはサーバ側にバージョンごとのキャッシュを保持しています。

例えば、現時点で最新が 2.3 のパッケージの 2.2 をインストール、みたいなことって出来るのかな、って思いました。

[myuhe]

@tkf
前のバージョンを残すということで、素朴なバージョン管理はできますね。

[tkf]

@myuhe ローカルに何もない状態(例えば ~/.emacs.d が空)で、って意味でした。

[myuhe]

@tkf そういう場合だと無理です。package.elにはサーバ側のバージョンを指定する機能はなかったはずです。強引に実現しようとすれば、サーバ側に違うパッケージ名で登録しないといけないんだと思います。

[tkf]

@myuhe なるほど。この辺り、どのくらいで改善してくれるんですかね。。。ローカルで、自分の使うパッケージすべてのバージョンを指定した -pkg.el を作ったらどうか、って思いましたがそれだと最低限必要なバージョンしか指定できませんね。

[tkf]

バージョンの話をしていたら見逃した package.el の利点を思い出しました。 el-get はパッケージのバージョンについて何も知ることが出来ないので、down streamのパッケージが依存パッケージの最低バージョンを変更した時に、その依存パッケージも同時に update するみたいなことが出来ません。 package.el だとこの欠点は出てこないですね。 MELPA 使っちゃうと意味なくなりますが。

[myuhe]

@tkf 込みいってくるとEmacs上のバージョン管理にはまだまだ穴がありますね。サーバ側で改善すべきことが多くあって個人の力ではなかなか動かしようがないところでもあり、改善のスピードはあまり早くないんではないかと思っています。
そうなると、OS側のバージョン管理の方が楽なような気がしていて、自分のとこでは一部をそっちの方に移行させてます。
個人的には、OS側のバージョン管理でなんでもできるのがベストかなーとは思ってます。

[Shougo]

@sabottenda cartonはどうなんですかね ? あくまでパッケージレベルでの依存関係の解決という
感じなので、全体をそれで管理というのには向いているんですかね ? テストでは使えそうですが。

興味があったのでEmacs cartonを調べてみました。コマンドラインから使用するみたいなのでWindowsでの使用には何がありそうです（動作しない？）。cartonは依存関係の抽出に重きを置いているようですね。

※：実装を見てみるとbashスクリプトだった。Windows 対応が壊滅的……。

[tkf]

carton の実装は emacs lisp モジュールを bash でラップ、みたいな感じです。ユーザーの emacs 設定を管理する場合は emacs lisp モジュールを直接ロードすると思うんで、 windows でも使えるんじゃないですかね。 carton で設定を管理をしたこと無いから想像ですが。

[Shougo]

ふむふむ。Emacs Lispから使うためのインタフェースがあるならその部分だけは使えそうですね。
Windows環境がサポートされているのかは気になりますが。