Contexte

J'utilise emacs quotidiennement, mais surtout pour faire avancer les choses. Je n'aime pas vraiment le personnaliser plus que l'ajout de packages et je n'aime pas le dépannage. Je veux qu'emacs disparaisse en arrière-plan comme le fait un bon système d'exploitation et continue avec les choses. Il y a quelque temps, j'ai constaté que cela el-getme permettait d'installer les packages dont j'avais besoin qui n'étaient pas disponibles avec package.elet m'a également donné plus de contrôle, comme la sélection de la maintbranche du mode Org plutôt que le bord de fuite qui peut causer des problèmes temporaires. Maintenant, je ne sais pas si je devrais utiliser el-getou non.

Question

el-getsemblait être une excellente solution pour les divers référentiels et hacks emacs là-bas. Il offrait des capacités qui n'étaient tout simplement pas possibles avec package.el. Maintenant que package.eldans les versions plus récentes d'emacs ( >=24.4) prend en charge plusieurs référentiels, quels sont les cas d'utilisation el-getet les alternatives similaires au gestionnaire de paquets intégré d'emacs?

Il y a des choses qui sont toujours impossibles avec ELPA, et il y a des choses qui seront toujours impossibles avec ELPA, car elles ne rentrent pas dans le concept d'ELPA: vous ne pourrez jamais installer un commit spécifique par son hachage à partir d'un fork dépôt. De même, vous ne pourrez jamais appliquer de correctifs locaux personnalisés à un package avant de l'installer. Ces fonctionnalités sont tout simplement hors de portée d'ELPA, et si vous en avez besoin, vous devrez utiliser un autre gestionnaire de paquets.

Je pense, cependant, que el-get est une sorte de solution héritée de nos jours. Étant donné qu'ELPA est devenu de facto le gestionnaire de packages standard pour Emacs, les gestionnaires de packages alternatifs devraient s'intégrer de manière transparente à ELPA. el-get, cependant, n'expose pas ses propres packages à ELPA, ce qui signifie que ses packages sont entièrement invisibles pour ELPA et que les packages ELPA ne peuvent jamais dépendre des packages el-get, avec des implications évidentes pour la gestion des dépendances.

Si vous avez besoin de fonctionnalités au-delà d'ELPA, vous devriez de nos jours regarder QUELPA plutôt que el-get.

J'ai écrit un nouveau gestionnaire de packages pour Emacs, straight.elqui tente d'améliorer toutes les solutions de gestion de packages existantes. Il existe une section complète dans la straight.eldocumentation sur les comparaisons avec d'autres gestionnaires de packages , mais voici un résumé très court:

• package.eltélécharge des tarballs opaques à partir de serveurs centraux, sans possibilité de sélectionner une version spécifique d'un package, et ne vous permet pas d'apporter des modifications locales à vos packages; apporter des changements en amont est impossible. straight.elclone les référentiels Git de manière décentralisée (mais il utilise automatiquement les recettes de MELPA , GNU ELPA et EmacsMirror , si vous le souhaitez), et vous permet de leur apporter des modifications locales arbitraires, de valider ces modifications et de contribuer en amont. Cela peut être fait manuellement ou vous pouvez utiliser les opérations de gestion de référentiel en vrac intégrées. Les modifications apportées à vos packages sont détectées automatiquement et aucune reconstruction manuelle n'est requise. En outre,straight.el prend en charge une reproductibilité complète pour votre configuration Emacs, car il vous permet d'écrire un fichier de verrouillage de révision qui inclut les hachages Git de tous vos packages.
• Quelpa et Cask sont tous deux basés sur package.el, et héritent de plusieurs des mêmes inconvénients. Par exemple, Cask n'a aucun concept d'installation d'une version particulière d'un package. Quelpa le fait, mais cela nécessite que vous codiez en dur le hachage Git dans votre fichier init. straight.elévite package.elentièrement, remplaçant toutes ses fonctionnalités de base par une conception unifiée adaptée à de nombreux autres cas d'utilisation.
• el-get a l'avantage que vous pouvez installer des packages à partir de n'importe où (tous les systèmes de contrôle de version connus, HTTP arbitraire, les gestionnaires de packages système, EmacsWiki, même go get!?). Cependant, en prenant en charge autant de sources, el-get ne peut pas fournir le type d'opérations avancées de gestion de packages (telles que la reproductibilité via les fichiers de verrouillage de révision et les opérations de gestion de référentiel interactif) qui les straight.elfournit. straight.elne supporte que Git, car la plupart des packages sont disponibles via Git et ceux qui ne le sont pas peuvent être obtenus via EmacsMirror (je vous défie d'en trouver un qui ne peut pas l'être!). Notez que straight.elfournit néanmoins une API extensible pour des backends de contrôle de version supplémentaires (par exemple pour Mercurial) à ajouter à l'avenir, si vous le souhaitez.
• Borg a une philosophie très similaire straight.elet offre plusieurs des mêmes avantages. Cependant, il n'a pas été conçu pour être un gestionnaire de package complet, et est conçu pour être utilisé dans le souci avec d' autres outils tels que epkg, auto-compileet Magit. Au contraire, straight.elest autonome et fournit tout ce dont vous avez besoin, nécessitant peu ou pas de configuration supplémentaire. En outre, Borg utilise des sous-modules Git, dont l'interface a des bords rugueux, tandis qu'il straight.elutilise des référentiels Git gérés indépendamment, offrant une flexibilité et une puissance supplémentaires.
• Il y a aussi l'approche manuelle, mais je ne le recommande pas. Après les deux premiers mois, vous auriez réinventé Borg. Ensuite, après les deux prochains mois, vous auriez réinventé straight.el. Vous en apprendrez beaucoup sur la gestion des packages, cependant;)

Bien qu'il y ait des avantages et des inconvénients, je pense que el-get est toujours pertinent, malgré les opinions fortes de @lunaryon (rejeep aussi).

J'ai utilisé raw package.el avec use-package pendant un certain temps (2 à 3 ans), puis je suis passé à el-get , puis à Cask . Je suis retourné à el-get il y a quelques jours. Avant package.el , comme beaucoup d'autres, je manipulais manuellement les modules complémentaires.

Pourquoi suis-je retourné à el-get ? J'ai rencontré une certaine bizarrerie Cask à propos de quelque chose qui n'est pas un dépôt git (un de mes paquets Github qui n'est pas dans MELPA), alors que ce paquet utilise en fait git ... Je n'ai pas pris la peine d'enquêter ou de créer un ticket, j'ai juste retiré mon ancien config el-get et j'étais prêt à partir en un rien de temps.

Peu de choses que j'aime chez el-get :

• Il prend en charge plusieurs récupérateurs, pas seulement git.
• Il contient suffisamment de recettes prédéfinies
• Plus rapide que Cask au démarrage.
• et oui @lunaryorn, le Wiki n'est pas un endroit pour distribuer du code, je ne veux toujours pas créer un dépôt Github s'il n'y a pas de clone sur emacsmirror (Github).
• Autonome, avec Cask, vous avez besoin d'une installation externe. J'utilise un seul fichier init (pas une configuration modulaire) avec allout-mode pour naviguer dans les sections.
• el-get est assez simple du point de vue de l'utilisateur.

Remarque: j'utilise Emacs Git HEAD sous OSX et Linux.

Vous voudrez peut-être y jeter un œil paradox. Ce n'est pas un autre gestionnaire de paquets, mais un frontal plus soigné pour package.el. Par exemple, lorsque vous mettez à jour des packages, il vous demande si vous souhaitez les installer et supprimer les anciens en une seule étape.

Si vous l' utilisez, vous voulez probablement ensemble paradox-execute-asynchronouslyà tdans votre fichier init.