Emacsでのパッケージ管理

私はかなり長い間Emacsを使用していますが、一般的には、すべてを連続して使用しています。 このテキストプロセッサで配布されるelispパッケージの数は常に増加していますが、サードパーティのパッケージをインストールする必要がある場合があります。 時間が経つにつれて、その数も徐々に増加し、依存関係を追跡する必要があります。また、一般に、パッケージマネージャーのタスクの標準セットを更新する必要があります（またはできれば）。 最近まで、Linuxタイプapt、portageのシステムパッケージマネージャーを使用して、elispパッケージをインストールしていました。 もちろん、不便な点もありましたが、実際の問題は、WindowsおよびMac OSでEmacsを使用する必要があるときに始まりました。 実際のパッケージ管理に加えて、〜/ .emacsの設定だけでなく、インストールされているすべてのファイルを同期する必要がありました。



その結果、できれば次の品質を備えた本格的なelispパッケージマネージャーを使用するように成熟しました。

• 大規模なパッケージデータベース
• 独自のパッケージを作成および維持する便利さ
• インストールされたパッケージのコンピューター間の同期の容易さ
• 追加のアプリケーションをインストールせずにクロスプラットフォーム

既存の可能性について少し調査した後、このレビューが判明しました。このレビューでは、elpaとel-getについて詳しく説明し、その他について簡単に説明します。







重要な注意：以下で説明するすべてはemacs 23の安定バージョンで試されました。以前のバージョンは説明どおりに動作しない場合があります。 異なるオペレーティングシステムでの特別なテストは実行されず、動作中にいくつかの小さなことが発見されました。

ELPAまたはpackage.el

最初は、Emacs Lisp Package Archive（これがelpaの略です）がここにありましたが、オリジナルはまだダウンロードしてインストールできます。 現在、package.elはemacs開発ツリーでサポートされており、リリース24に含まれます。つまり、elpaには潜在的に大きなユーザーベースがあるため、パッケージベースが開発されます。 ちなみに、これはおそらくEmacs Starter Kitにキー設定されています。これはおそらく初心者向けのelpaをインストールする最も簡単な方法であり、さらにemacs 22でも機能しますが、私の目的にはあまりにも不必要です。 package.elはemacs開発ツリーから取得する方がはるかに簡単です。package.elが完全に独立しなくなったため、 このバージョンをお勧めします。



したがって、〜/ .emacs.d / elpaフォルダーを作成して、インストールされているすべてのパッケージを保存し、ダウンロードしたファイルをそこに置き、次の行を〜/ .emacsに追加します。

;;; This was installed by package-install.el.

;;; Move this code earlier if you want to reference packages in your .emacs.

(when (load (expand-file-name "~/.emacs.d/elpa/package.el"))

(package-initialize))



このコマンドを実行した後（または最悪の場合emacsを再起動した後）、Mx list-packagesを試して、データベースからパッケージのリストを取得および表示できます。 デフォルトでは、 http：//elpa.gnu.orgが使用されます。そこにはかなりの数のパッケージがあるため、リポジトリを追加します。

;; use more repositories for elpa

(setq package-archives '(("elpa" . "http://tromey.com/elpa/")

("gnu" . "http://elpa.gnu.org/packages/")

("marmalade" . "http://marmalade-repo.org/packages/")))



長所：

• emacsの将来のバージョンでのサポートの保証。
• 絶対にクロスプラットフォームの純粋なelisp。
• 集中リポジトリにより、新しいパッケージを簡単に見つけてテストできます。
• パッケージを検索および表示するための優れたインターフェース。

短所：

• （未）インストール済みパッケージに関する追加情報はほとんどありません。インストール日、リポジトリ名などはありません。
• インストール済みパッケージのリストをサポートしていないため、異なるマシンでパッケージを同期するのが難しくなります。
• パッケージと依存関係を削除できません

現在までに、リポジトリには約330のパッケージがあり、数か月前には約280のパッケージがありましたが、進展は明らかです。

el-get.el

GitHubで見つけることができます（他の場所？）。ここで、著者はEmacs Starter Kitの代替としてEmacs Kickerを提案しています。 コマンドを1つ実行するだけで、elpaと同じようにel-getをインストールできます。コマンドはインストールスクリプトをダウンロードし、githubからリポジトリを〜/ .emacs.d / el-getにクローンして初期化します。 〜/ .emacs.dはすでにgitの監視下にあるため、gitサブモジュールを使用しました。

cd ~

mkdir .emacs.d/el-get

git submodule add github.com/dimitri/el-get.git .emacs.d/el-get/el-get



これにより、マネージャーとパッケージデータベース（ レシピ ）の両方を簡単に更新できます。 レシピからのすべてのパッケージは〜/ .emacs.d / el-getにインストールされ、elpaパッケージと混ざりません。 開始するには、次を〜/ .emacsに追加する必要があります。

;;; check if git sumbodule is there before loading el-get

(when (file-readable-file "~/.emacs.d/el-get/el-get/el-get.el")

(add-to-list 'load-path "~/.emacs.d/el-get/el-get")

(require 'el-get)

;; packages to manage

(setq el-get-sources

'((:name magit :type elpa)

))

(setq recipes

(append

'(bbdb mediawiki auctex)

(mapcar 'el-get-source-name el-get-sources)))

(el-get 'sync recipes))



el-getをダウンロードした後、コードはインストールされたパッケージをチェックし、不足している場合はインストールを試みます。 したがって、el-get、bbdb、mediawiki、およびauctexは独自のレシピからインストールされ、magitはelpaを使用してインストールされます。 さらに、apt-get、git、 その他すべてからのインストールが可能です。 同時に、elpaとapt-getはパッケージを別々のフォルダーにインストールし、原則として、パッケージを個別に管理できます。 el-getはディレクトリ内にシンボリックリンクを作成し、パッケージが外部から削除されると不快になるため、これは推奨されません。 一般に、上記のように、インストールされたパッケージのリストとオプションを1つの場所に保存する方が適切です。これにより、コンピューター間の同期が大幅に簡素化されます。



レシピはMx el-get-installを使用してインタラクティブにインストールすることもできますが、トラップに入ることもできます：すでにインストールされているパッケージは自動補完リストに表示されないため、データベースにないという誤った印象を受けるかもしれません。 これは、パッケージのリストを明示的に保持するもう1つの理由です。



同期といえば。 必要なものをすべて新しい場所にインストールするには、emacsを起動する前にいくつかのコマンドを実行するだけです。

cd ~

git submodule init

git submodule update



emacsを（再）起動すると、すべてが自動的にインストールされます。 確かに、いくつかの落とし穴があります。

1. emacsに加えて、パッケージをコンパイルするために追加のプログラムが必要な場合、それらをインストールして動作させる必要があります。 emacs-w3mを例に挙げましょう。ソースをダウンロードするにはcvs、コンパイルするにはautoconfが必要です。 正直なところ、emacs-w3mをWindowsで動作させることはできませんでした。
2. apt-getを使用する場合、Linuxではパッケージはdebian派生物にのみインストールでき、Mac OSではFinkを使用できます（el-getもサポートしています）が、これは万人向けではありません。 さらに、このようなパッケージはシステムにインストールされるため、管理者権限が必要です。
3. サードパーティのパッケージマネージャーでシンボリックリンクを使用すると、Windows XPでの生活が大幅に複雑になり、愚かにはサポートされません。 不安定なブランチで修正されているようですが、まだ試していません。

長所：

• インストール済みパッケージのリストを保持します。
• パッケージを削除できます。
• バージョン2.2以降では、el-getには適応バージョンが含まれているため、elpaでのすべての操作は不要になります。
• 原則として、クロスプラットフォーム（上記の落とし穴を参照）;
• 積極的に開発されました。

短所：

• バージョンをまったく追跡しません。
• 非常に不便なインターフェース：レシピからのパッケージの名前はオートコンプリートを使用して表示でき、el-get-describeで追加情報を要求できますが、elpaのような説明付きの美しいリストはありません。

レシピには約350個のパケットが見つかり、elpaパケットを追加すると、かなり美しい数になります。 原則として、 emacswikiからパッケージをインストールできます。これは約1660パッケージです。

残り

私は残りのパッケージマネージャーを非常に簡単に調べました;マネージャーのリストと追加情報はEmacsWikiとStackOverflowにあります。

• 自動インストール ：emacswikiを一元化されたパッケージデータベースとして使用し（他のオプションも可能）、依存関係を追跡し、バージョン間の違いを表示できます。 el-getからインストールできます。
• elinstall.el ：あまり明確ではないドキュメント。
• epackage ：分散Emacs Lispパッケージシステム（DELPS）になるはずです。パッケージの保存と配布はgitによって使用されます。 アイデアは悪くないかもしれませんが、数十個のパケットのために、ツリー全体をディスク上に保持するために私は微笑んではいません。 そして、一般的に、開発は何らかの形で停滞しています。
• epkg.el ：まだアップロードされていない6か月の開発期間のgitも使用しています。
• install.el ：サポートされなくなったようです。著作権2006年の最新の日付です。
• install-elisp.el ： auto-installの前身はサポートされなくなりました
• jem-pkg.el ：興味深い機能のうち、マシンごとに異なる構成をサポートしていますが、すべてのコンピューターで同じパッケージと設定をサポートする必要があるだけです。 また、パッケージの入手先が明確ではありません。
• pases.el ：パッケージはMakefileの形式で作成され、それらを収集する必要があり（手動で？）、pasesはemacsにインストールします。 まあ、非常に少数のパッケージがあり、一般的に、学生論文のように見えます。
• pelm ：PHP Emacs Lisp Manager、真のemacs'ovoduが再送されました。
• plugin.elとuse-package.elは明らかにサポートされていません。

結論の代わりに、現時点では上記のel-get + elpa束を使用していることに注意してください。 時間が表示されたら、自動インストールで遊んで、それについてhabrasocietyに伝えると思います。