バックグラウンド

私はemacsを毎日使用していますが、ほとんどは物事を成し遂げるためです。パッケージを追加するよりもカスタマイズするのはあまり好きではなく、トラブルシューティングも好きではありません。優れたOSのようにemacsをバックグラウンドにフェードインさせて、物事に取り掛かりたいです。少し前に el-get、必要なパッケージをインストールできるようになり、使用できないパッケージをインストールできるようになり、一時的な問題を引き起こす可能性のある最先端ではなく、Org-modeのブランチをpackage.el選択するなどの制御maintが可能になりました。今、私は私が使用すべきかどうかわからel-getない。

質問

el-getさまざまなリポジトリとemacsのハックに対する素晴らしい解決策のように思えました。それは単に可能ではなかった能力を提供しましたpackage.el。現在package.el、emacs（>=24.4）の新しいバージョンでは複数のリポジトリをサポートしていますが、el-getemacsの組み込みパッケージマネージャーのユースケースと同様の代替手段は何ですか？

ELPAではまだ不可能なことがあります。ELPAの概念に適合しないため、ELPAでは常に不可能なことがあります。フォークからのハッシュによって特定のコミットをインストールすることはできません。リポジトリ。同様に、インストールする前にパッケージにカスタムローカルパッチを適用することはできません。これらの機能はELPAの範囲を超えているため、必要な場合は代替のパッケージマネージャーを使用する必要があります。

しかし、このel-getは最近のレガシーソリューションのようなものだと思います。ELPAがEmacsの事実上の標準パッケージマネージャーになったことを考えると、代替パッケージマネージャーはELPAとシームレスに統合する必要があります。ただし、el-getは独自のパッケージをELPAに公開しません。つまり、そのパッケージはELPAから完全に不可視であり、ELPAパッケージは依存関係管理に明らかな影響を与えることなく、el-getパッケージに依存できません。

ELPA以外の機能が必要な場合は、今日ではel-getではなくQUELPAを検討する必要があります。

Emacs用の新しいパッケージマネージャーを作成しましたstraight.el。これは、既存のすべてのパッケージ管理ソリューションの改善を試みます。ドキュメントには、他のパッケージマネージャーとの比較に関する広範なセクションがありますが、ここに非常に短い要約があります。straight.el

• package.elパッケージの特定のバージョンを選択するオプションなしで、中央サーバーから不透明なtarballをダウンロードします。パッケージにローカルな変更を加えることはできません。上流での変更の貢献は不可能です。straight.el分散型の方法でGitリポジトリのクローンを作成します（ただし、必要に応じてMELPA、GNU ELPA、およびEmacsMirrorからのレシピを自動的に使用します）。これは手動で行うことも、組み込みのバルクリポジトリ管理操作を使用することもできます。パッケージへの変更は自動的に検出され、手動での再構築は必要ありません。さらに、straight.el すべてのパッケージのGitハッシュを含むリビジョンロックファイルを作成できるため、Emacs設定の完全な再現性をサポートします。
• QuelpaとCaskはどちらもに基づいておりpackage.el、同じ欠点の多くを継承しています。たとえば、Caskには、パッケージの特定のバージョンをインストールするという概念はありません。Quelpaはサポートしていますが、Gitハッシュをinitファイルにハードコードする必要があります。すべてのコア機能をより多くのユースケースに合わせた統一された設計に置き換え、完全にstraight.el回避package.elします。
• el-getには、どこからでもパッケージをインストールできるという利点があります（すべての既知のバージョン管理システム、任意のHTTP、システムパッケージマネージャー、EmacsWiki、go get！？）。ただし、非常に多くのソースをサポートしているため、el-getは、高度なパッケージ管理操作（リビジョンロックファイルによる再現性や対話型リポジトリ管理操作など）をstraight.el提供できません。straight.elほとんどのパッケージはGitを介して利用でき、EmacsMirrorを介して入手できないパッケージがあるため、Gitのみをサポートしています（できません！straight.elそれでも、必要に応じて、将来追加されるバージョン管理バックエンド（Mercurialなど）用の拡張可能なAPIが提供されることに注意してください。
• ボルグの哲学は非常に似てstraight.elおり、多くの同じ利点があります。しかし、完全なパッケージマネージャになるように設計されていない、とのような他のツールと懸念して使用するように設計されてepkg、auto-compileとMagit。それどころか、straight.el自己完結型であり、必要なものはすべて単独で提供され、追加の構成はほとんど必要ありません。また、BorgはGitサブモジュールを使用しますが、そのインターフェイスにはいくつかのラフなエッジがありますが、straight.el独立して管理されたGitリポジトリを使用するため、柔軟性とパワーが向上します。
• 手動によるアプローチもありますが、これはお勧めしません。最初の数か月後、ボルグを再発明したでしょう。それから数ヶ月後、あなたは再発明したでしょうstraight.el。ただし、パッケージ管理について多くのことを学びます;）

長所と短所がありますが、@ lunaryonの強い意見にも関わらず、el-getはまだ関連があると思います（リジェップも）。

生のpackage.elとuse-packageをしばらく（2〜3年）使用してから、el-get、Caskに切り替えました。数日前にエルゲットに戻りました。以前のpackage.elは、他の多くの製品と同様に、アドオンを手動で処理していました。

なぜel-getに戻ったのですか？gitリポジトリ（MELPAにない私のGithubパッケージ）ではない何かについてのCaskの奇妙なことに遭遇しましたが、そのパッケージは実際にgitを使用しています... el-get configと私はすぐに行って良かったです。

el-getについて好きなことはほとんどありません。

• gitだけでなく、複数のフェッチャーをサポートします。
• 十分な定義済みレシピが含まれています
• 起動時のCaskよりも高速。
• そして、はい@ lunaryorn、Wikiはコードを配布する場所ではありませんが、emacsmirror（Github）にクローンがなければGithubリポジトリを作成したくありません。
• 自己完結型で、Caskでは外部インストールが必要です。allout-modeで単一の初期化ファイル（モジュール構成ではない）を使用してセクションをナビゲートします。
• el-getは、ユーザーの観点からは非常に単純です。

注：OSXおよびLinuxでEmacs Git HEADを実行しています。

あなたが見てみたいかもしれませんparadox。これは別のパッケージマネージャーではなく、のすっきりしたフロントエンドですpackage.el。たとえば、パッケージを更新すると、パッケージをインストールして古いパッケージを削除するかどうかをワンステップで尋ねられます。

使用する場合は、おそらくinitファイルでに設定paradox-execute-asynchronouslyする必要がありtます。