Quelles sont les différences pratiques entre les différents référentiels de paquets Emacs?

Je remarque qu'il existe plusieurs référentiels différents qui contiennent souvent le même logiciel. Pourquoi voudrais-je préférer:

• GNU ELPA
• Confiture
• MELPA

sur les autres? Puisqu'un référentiel ne contient pas tous les packages que je veux, est-ce une bonne idée d'activer ces référentiels simultanément?

GNU ELPA est le référentiel officiel des paquets GNU Emacs. C'est le seul activé par défaut, ce qui signifie qu'il a la plus grande portée. Dans le même temps, la soumission d’un paquet est un peu fastidieuse et nécessite une cession des droits d’auteur de la FSF, ce qui signifie que la sélection de paquets est relativement limitée.

MELPA et Marmalade sont tous deux des référentiels de packages tiers. Ils ne sont pas officiellement supportés par GNU, mais ont également une plus grande sélection de paquets. La qualité de l'emballage est un peu plus variable, mais vous êtes beaucoup plus susceptible de trouver ce que vous cherchez, surtout s'il est un peu obscur.

Marmalade et MELPA ont des modèles légèrement différents pour les téléchargeurs de paquets. D'après ce que je comprends, MELPA suit directement un référentiel de contrôle de version (c.-à-d. Via GitHub), permettant ainsi aux auteurs de packages de mettre à jour des packages simplement en transmettant des commits à une branche. De son côté, Marmalade demande aux personnes de télécharger explicitement des packages dans le référentiel.

En pratique, je n'ai pas vu beaucoup de différence entre MELPA et Marmalade. Il n'y a pas beaucoup d'inconvénients à leur permettre d'avoir le plus grand choix possible de paquets installables: j'utilise les deux (et GNU ELPA, bien sûr) depuis un moment, sans aucun problème significatif.

Une des préoccupations possibles (que je ne me suis pas heurtée moi-même) avec l'activation des deux référentiels, que je ne me suis pas heurté moi-même, est d'avoir des packages disponibles dans les deux versions. Par défaut, le gestionnaire de paquets ( package.el) ne dispose d'aucun moyen de résoudre un conflit comme celui-ci; Toutefois, vous pouvez résoudre ce problème en installant le melpapackage qui vous permet de personnaliser les packages fournis ou exclus de chaque référentiel. Vous pouvez voir plus de détails ici ou à partir de la documentation du melpapaquet.

Comme @Malabarba l'a gentiment souligné, ce problème est résolu dans Emacs 24.4.

Si la sécurité vous inquiète vraiment, évitez peut-être MELPA et Marmalade, car ils permettent à quiconque de télécharger des packages et, autant que je sache, ne disposent d’aucune disposition proactive en matière de sécurité. Le référentiel GNU ELPA, en revanche, est géré par la FSF et a signé des paquetages qui devraient aider. Bien sûr, si la sécurité est vraiment importante, vous voudrez peut-être simplement passer en revue et installer les paquets elisp manuellement plutôt que d'utiliser le gestionnaire de paquets.

D'après ce que j'en pense, certaines opérations de pension impliquent plus de frais généraux liés à la soumission des colis que d'autres; les pensions avec plus de frais généraux ont tendance à avoir moins de paquets. Du plus au moins frais généraux:

1. GNU ELPA exige que tout le code soit au format GPL et que les droits d’auteur soient attribués à la FSF. Le code ELPA est essentiellement "détenu" par l'équipe principale d'Emacs, il est donc beaucoup moins copieux que dans les autres pensions. (Le mode org a son propre référant, mais il a le même mode de fonctionnement.)
2. Marmalade exige que tout le code ait une licence compatible avec la GPL et que tous les packages sont téléchargés manuellement. La propriété est un peu indéterminée, et le changement de propriété n'a pas de processus prédéfini selon les critères de l'Afrique.
3. MELPA Stable est plus ou moins en concurrence directe avec Marmalade, à l'exception du fait qu'il n'a aucune restriction de licence et qu'il construit automatiquement des packages à partir de mises en pension git en utilisant la dernière révision étiquetée. La propriété est déterminée par le référentiel MELPA (les changements de propriété se produisent par demande d'attraction).
4. MELPA est semblable à MELPA stable, à la différence qu’il tire toujours de la dernière révision de la branche principale d’un dépôt Git. Les paquets ont tendance à être à la pointe du progrès, et cela peut être un peu une stabilité totale (ce qui a des avantages et des inconvénients).

Personnellement, je pense que MELPA Stable ou Marmalade l'emportera probablement sur le long terme pour la plupart des utilisateurs - MELPA proprement dit est plutôt instable et ELPA est trop restrictif pour être réellement évolutif pour de nombreux packages. Mais ce n'est qu'un avis.

Plusieurs référentiels de packages sont disponibles.

Officiel

GNU ELPA est le paquetage officiel. C'est petit et il faut céder les droits d'auteur (de tous les auteurs d'un paquet) à la FSF pour y contribuer.

Les paquets sur GNU ELPA ne sont en réalité qu’un repo git . L’avantage d’être hébergé ici réside dans le fait que l’équipe principale essaie de mettre à jour les paquetages si Emacs ajoute ou déprécie des fonctionnalités.

Construit à partir de la source

MELPA est le dépôt de colis le plus important et dont la croissance est la plus rapide . Il publie une nouvelle version chaque fois qu'une nouvelle version est poussée dans un référentiel ou qu'une page EmacsWiki est mise à jour.

C'est un avantage, mais cela fonctionne très bien dans la pratique. MELPA est conçu pour éviter les paquets en double et pour s'assurer que la maison canonique du paquet est enregistrée (au lieu d'un fork) aléatoire.

MELPA a le problème que les versions ne sont que des horodatages, par exemple my-package-20131231.2359. Cela signifie que si vous dépendez de my-package:

;; Package-Requires: ((my-package "1.2.3"))

Emacs pensera alors que toute version de MELPA est suffisamment nouvelle.

MELPA Stable est identique à MELPA, mais plutôt que d'utiliser des versions d'horodatage, il utilise les versions des balises git. Cela permet une meilleure résolution de la dépendance, mais pose des problèmes de dépendance aux paquets wiki .

Téléchargements de l'utilisateur

Marmalade ressemble beaucoup plus à un référentiel traditionnel d'autres langages de programmation. Le développeur de package télécharge le package dans Marmalade lors de la publication.

En principe, cela donne aux paquets un processus de publication approprié (Marmalade est antérieur à la version stable de MELPA) et évite également le problème du numéro de version généré automatiquement. Cependant, il n'y a pas de vérification d'identité. Tout le monde peut télécharger un paquet, même s'il ne l'a pas écrit. Cela devient difficile si le responsable de my-packagetrouve que quelqu'un d'autre a téléchargé my-packageet ne peut pas télécharger ultérieurement de nouvelles versions.

Marmalade était une application node.js, et elle est maintenant écrite en elisp. Les deux versions ont parfois eu des problèmes de disponibilité.

Spécifique au projet

ELPA en mode organisationnel est un repo qui ne héberge que orget org-plus-contrib. Le mode Org fait partie du noyau Emacs, mais il est développé en externe et le code n'est synchronisé que périodiquement avec le tronc Emacs. Ce référentiel vous permet d’avoir le mode org à la pointe de la technologie.

User42 ELPA est un référentiel pour un développeur de paquetages unique qui a publié toute une gamme de paquets Emacs . Si vous aimez l'un de ses packages, vous pouvez ajouter ce dépôt.

Sunrise Commander ELPA est un référentiel d’extensions pour Sunrise Commander (un package Emacs pour la navigation dans les fichiers, inspiré de minuit commandant).

Retraité

ELPA de Tromey a été la première mise en place de référant . Il est officiellement remplacé par GNU ELPA, mais il n’était pas soumis aux mêmes exigences d’attribution de droits d’auteur. À partir de 2010, il n'est plus mis à jour.

L'archive de paquets Elpy contenait divers packages développés par Jorgen Schaefer pour 'Elpy, l'environnement de développement Emacs Python' , mais ayant migré vers MELPA Stable.

Quelques informations supplémentaires, pour compléter les autres réponses ici.

1. Quelques infos sur MELPA et MELPA "stable" -

   Commencez par examiner cette question très dupliquée de StackOverflow, y compris les commentaires de la question elle-même. En particulier, ce commentaire que j'ai posté, après avoir échangé un courrier électronique avec Donald Curtis (mainteneur de MELPA et de MELPA stable):

   De son point de vue [de Donald Curtis, et si j'ai bien compris sa communication], le site "stable" de MELPA est uniquement en mode maintenance . Et la seule raison pour laquelle un code comme le mien n’existe pas, c’est que personne n’a implémenté le téléchargement depuis le wiki [Emacs Wiki] pour le site "stable". De plus, personne ne fait de "curating" - pas de filtrage pour déterminer si un paquet est stable, risqué, etc. L’existence de deux sites a été demandée par certains développeurs de paquets qui voulaient distinguer les versions dev de leurs paquets d’anciens ("stable"). ") versions.

   En résumé, rien dans le contenu de "MELPA stable" n'est par nature plus "stable" . La numérotation des versions et la méthode d'alimentation peuvent être différentes. c'est tout. Et si un mainteneur de paquet particulier veut distinguer les versions "stable" de "développement" et veut le faire en les téléchargeant sur les deux sites différents, alors c'est l'effet - pour ce paquet .

2. Une différence entre MELPA et Marmalade (et GNU ELPA) réside dans le fait qu’il n’est pas nécessaire que le code fourni à MELPA soit issu d’un référentiel git. En particulier, il peut être automatiquement extrait de la zone Elisp du wiki Emacs .

   Cela signifie-t-il, comme certains l’ont dit, que tout le monde peut télécharger quelque chose et que vous n’avez aucun moyen de savoir si le code provient bien de l’auteur revendiqué, etc.? Oui et non. En général, oui: tout le monde est libre de télécharger du code Elisp sur le wiki d'Emacs. Comme le dit le haut de la page Elisp-Area:

   C'est la zone elisp d'EmacsWiki, où nous collectons les fichiers EmacsLisp. Aucune connexion requise, aucun contrôle de version requis, aucun ftp requis, aucun mot de passe requis. C'est aussi simple que le wiki lui-même. Cela signifie également que n'importe qui peut placer un code malveillant dans ces fichiers EmacsLisp. En cas de doute, ne les utilisez pas.

   Cependant, juste pour que vous le sachiez, je suis un administrateur du wiki et mes propres bibliothèques Lisp dans la zone wiki Elisp sont des pages verrouillées. Cela signifie que seul un administrateur du wiki peut les télécharger. Donc, dans ce cas, vous pouvez être sûr que les bibliothèques que j'ai téléchargées à partir de MELPA ou d'Emacs Wiki ont été téléchargées par moi. Toutefois, comme pour tout ce qui existe sur Internet, il n’ya aucune garantie absolue, tout comme il n’ya aucune garantie avec le code lui-même. Comme l'indique le texte GPL dans chaque bibliothèque GPL:

   Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE; sans même la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la licence publique générale GNU pour plus de détails.

HTH. Heureux piratage.