Je remarque que certains mainteneurs de packages notables choisissent de ne pas utiliser le système de gestion de packages Emacs (ESS?) Ou se plaignent de ses limites (Helm).
AVERTISSEMENT : en raison d'un mauvais concept de package.el qui est chargé de récupérer les fichiers de barre et de les compiler, les utilisateurs ont la plupart du temps des erreurs lors de la mise à niveau de melpa et list-package. Pour éviter cela, Async a été ajouté en tant que dépendance à helm pour forcer package.el à compiler ses fichiers dans un environnement propre. Les personnes installant à partir de git et utilisant le fichier make ne souffriront pas de ce problème et n'ont pas besoin d'Async bien qu'il soit recommandé car il corrige l'installation de tous les autres packages que vous pouvez installer avec package.el de (m) elpa. Voir FAQ pour plus d'infos.
À quelles limitations techniques précises le système de gestion de packages actuel pourrait-il faire allusion, et pourquoi les packages devraient-ils être utilisés asynccomme dépendance?
la source
Réponses:
Le problème auquel vous faites référence est probablement que lorsque vous mettez à niveau un package à partir d'une session Emacs où ce package est déjà utilisé, l'ancienne version du package interfère parfois lors de la compilation de la nouvelle version, ce qui entraîne des fichiers mal compilés.
Il y a une solution provisoire pour cela dans Emacs-25, mais AFAIK le problème est toujours présent dans 24.5.
la source
À l'exception notable de ProofGeneral, je ne connais aucun package Emacs majeur qui n'est pas disponible dans certaines archives ELPA. Plus précisément, ESS est sur MELPA depuis trois ans . Et PG est une histoire à part entière, et certainement pas représentative de l'ensemble de l'écosystème Emacs.
ELPA a certainement ses défauts, mais pour la grande majorité des packages, il fonctionne très bien, même pour les plus gros comme Magit. Helm est le seul paquet que je vois se plaindre de l'ELPA. Je ne sais pas exactement de quoi ils se plaignent, mais je suppose que cela concerne la compilation:
Pendant les mises à niveau, Emacs compile la nouvelle version du package dans un environnement où l'ancienne version est toujours chargée. Normalement, cela ne fait aucun mal, mais cela peut casser des macros dans certaines situations. Emacs compilera la nouvelle version par rapport à l' ancienne implémentation de la macro, ce qui peut provoquer une rupture si le nouveau code s'appuie sur une modification spécifique de cette macro.
Étant moi-même un responsable du package, je suis en désaccord avec cette affirmation. J'ai tendance à blâmer Helm plutôt que ELPA ou Emacs. À mon avis, l'énoncé est une hyperbole et le problème n'est qu'un symptôme de la surutilisation et de l'utilisation abusive des macros.
Si vous utilisez beaucoup de macros et - pire encore - mettez du code non trivial dans le corps des macros, vous devez simplement être conscient des implications que cela a pour la compilation d'octets et vous devez faire attention à maintenir la compatibilité descendante avec vos propres macros dans votre colis. Ne pas le faire, et plutôt rejeter la faute, n'est pas une très bonne chose à faire. Mes 2 cents.
la source