パッケージメンテナーがEmacsパッケージマネージャーを使用しないようにするための技術的な考慮事項？

著名なパッケージメンテナーがEmacsパッケージ管理システム（ESS？）を使用しないことを選択している、またはその制限（Helm）に不満を持っていることに気付いています。

HelmのREADME.mdからの引用：

警告：helmファイルのフェッチとコンパイルを担当するpackage.elの悪い概念が原因で、melpaおよびlist-packageからのアップグレード時に、ユーザーはほとんどの場合エラーを抱えていました。これを回避するために、package.elがクリーンな環境でファイルをコンパイルするように、helmへの依存関係として非同期が追加されました。（m）elpaのpackage.elでインストールできる他のすべてのパッケージのインストールを修正するために推奨されますが、gitからインストールしてmakeファイルを使用する人はこの問題に悩まされることはなく、非同期も必要ありません。詳細については、FAQを参照してください。

現在のパッケージ管理システムには、それが示唆している正確な技術的制限があり、パッケージがasync依存関係として使用する必要があるのはなぜですか？

あなたが言及している問題は、おそらく、そのパッケージがすでに使用されているEmacsセッション内からパッケージをアップグレードするときに、古いバージョンのパッケージが新しいバージョンのコンパイル中に干渉し、誤ってコンパイルされたファイルにつながることです。

Emacs-25には暫定的な修正がありますが、問題は24.5でもまだ存在しています。

ProofGeneralの注目すべき例外を除いて、一部のELPAアーカイブで利用できない主要なEmacsパッケージについては知りません。具体的には、ESSは3年前から MELPAを利用しています。そしてPGはそれ自体がストーリーであり、Emacsエコシステム全体を代表するものではありません。

ELPAには確かに欠陥がありますが、大多数のパッケージでは、Magitなどの大規模なパッケージでも問題なく動作します。Helmは、ELPAについて不満を感じている唯一のパッケージです。彼らが不平を言うのは正確にはわかりませんが、コンパイルに関するものだと思います。

アップグレード中、Emacsは古いバージョンがまだロードされている環境でパッケージの新しいバージョンをコンパイルします。通常、これはまったく害を及ぼしませんが、特定の状況でマクロを壊す可能性があります。Emacsは、マクロの古い実装に対して新しいバージョンをコンパイルします。これは、新しいコードがそのマクロの特定の変更に依存している場合、破損を引き起こす可能性があります。

私自身もパッケージのメンテナーなので、私はこの声明にかなり反対します。ELPAやEmacsではなくHelmを非難する傾向があります。私の意見では、ステートメントは誇大広告であり、問​​題はマクロの過剰使用と過剰使用の症状です。

多数のマクロを使用し、さらに悪いことに、マクロの本体に重要なコードを挿入する場合、これがバイトコンパイルに与える影響に注意し、独自のマクロとの下位互換性を維持するように注意する必要があります。パッケージ内。そうしないで、代わりに非難を渡すことは、行うのにあまり良いことではありません。私の2セント。