Qu'attendez-vous d'un gestionnaire de paquets pour Emacs? [fermé]

StackOverflow https://stackoverflow.com/questions/454259

Question

Bien que plusieurs milliers de bibliothèques Lisp Emacs existent, GNU Emacs, jusqu’à la version 24.1, n’avait pas de gestionnaire de paquets (interne).

Je suppose que la plupart des utilisateurs s'accorderont pour dire qu'il est actuellement plutôt fastidieux de rechercher, d'installer et surtout de conserver les bibliothèques Lisp d'Emacs les plus récentes.

Des pages qui simplifient un peu la vie

Pour les versions d'Emacs antérieures à 24.1:

  • Liste Emacs Lisp - Problème: I voir les personnes décédées (liens).
  • Emacswiki - Problème: peut contenir des traces de nut (code malveillant).
  • Emacsmirror - Le référentiel de paquets sur lequel je travaille. Problème: Aucun gestionnaire de paquets ne le supporte encore en mode natif.

Certains gestionnaires de packages

Ce n’est pas que personne n’a encore essayé. (Certains d'entre eux n'existaient pas lorsque cette question a été posée.)

UPDATE - package.el est inclus dans GNU Emacs à partir de la version 24.1

Le paquet

a été inclus dans le coffre d’Emacs. epkg n'est pas encore prêt et n'est pas disponible pour le moment. Au moins, install-elisp, le plug-in et use-package ne semblent plus être activement maintenus.

J'ai créé un référentiel git contenant tous ces gestionnaires de packages en tant que sous-modules. / p>

Certains utilitaires qui pourraient être utiles

Les gestionnaires de paquets pourraient utiliser ces utilitaires et / ou ils pourraient être utilisés pour conserver un miroir des paquets.

Discussions sur le sujet à l'étude

La question (enfin)

Alors, j'aimerais savoir ce que vous considérez comme important / sans importance / supplémentaire, etc. dans un gestionnaire de paquets pour Emacs.

Quelques idées

  1. De nombreux packages ( Emacsmirror fournissent la plus grande collection de packages disponible, mais aucun support explicite n'est fourni. gestionnaire de paquets encore).
  2. Seuls les packages qui ont été testés.
  3. Prise en charge de plusieurs archives de packages (afin que les utilisateurs puissent choisir entre plusieurs packages / testés).
  4. Dépendance calculée en fonction des fonctionnalités requises uniquement.
  5. Les dépendances prennent en compte des versions particulières.
  6. Utilisez uniquement les versions publiées en amont.
  7. Utilisez les versions des systèmes de contrôle de version, le cas échéant.
  8. Les packages sont classés par catégories.
  9. Les packages peuvent être désinstallés et mis à jour non seulement installés.
  10. Prise en charge de la création d'une fourchette pour la version en amont des packages.
  11. Supportez la publication de ces forks.
  12. Assistance dans le choix d'une fourchette.
  13. Une fois les packages d'installation activés.
  14. Générer des fichiers à chargement automatique.
  15. Intégration avec Emacswiki (voir wikirel.el).
  16. Les utilisateurs peuvent baliser, commenter, etc. les packages et partager ces informations.
  17. Uniquement les logiciels attribués à la FSF / GPL / FOSS ou ne vous souciez pas de la licence.
  18. Le gestionnaire de paquets doit être intégré et distribué avec Emacs.
  19. Assistance pour contacter facilement l'auteur.
  20. Beaucoup de métadonnées.
  21. Suggérez des alternatives avant d'installer un paquet particulier.

J'espère que ce genre de réponses

  • Pointeurs vers d'autres implémentations, discussions, etc.
  • Les longues descriptions d'un ensemble de fonctionnalités qui constituent votre gestionnaire de paquets idéal.
  • Descriptions d'une fonction particulière souhaitée / non souhaitée
Était-ce utile?

La solution

Publication automatique à partir du contrôle de version

J'aimerais beaucoup voir un gestionnaire de paquets Emacs standard, central et single . Pour le moment, je mettrais mon argent dans ELPA , mais le chemin à parcourir est encore long.

La plus grande chose qui aiderait un gestionnaire de paquets Emacs serait de rendre super simple la publication de paquets. À mon avis, j'aimerais que cela se produise en combinaison avec un système de contrôle de version tel que git sur une plateforme hébergée centrale telle que GitHub : les auteurs pourront plus facilement publier leurs packages et les autres utilisateurs.

Semblable à la façon dont GitHub (utilisé pour) facilite la publication de RubyGems, j'aimerais voir quelque chose de similaire dans un gestionnaire de paquets Emacs. Par exemple, balisez votre référentiel avec " vX.Y.Z " et que votre bienfait elisp soit automatiquement disponible pour tous.

L'avantage supplémentaire d'utiliser un backend populaire tel que GitHub est que vous obtiendrez immédiatement une bonne visibilité, ce qui devrait contribuer à son succès.

Autres conseils

J'apprends toujours Emacs. Je n'ai donc pas eu la possibilité de consulter les gestionnaires de paquets, mais une fonction intéressante serait d'informer l'utilisateur que le paquet est disponible s'il essaie de l'utiliser, mais ce n'est pas sur son compte. système. Par exemple, je voulais éditer un fichier PHP sur un serveur une fois, et j’ai essayé 

M-x php-mode

et Emacs était tout comme 

M-x php-mode [no match]

quand cela aurait dû être comme 

php-mode available from ftp.gnu.org. install? (y/n)

et puis il aurait installé et chargé en mode php pour moi. Cela aurait fait ma journée juste là.

Ce que j'attends le plus, c'est que tout tout ce qui est utile se trouve dessus et fonctionne bien. Pour ce faire, vous (ou une équipe de responsables) devez rechercher de manière agressive tout ce que vous voulez dans le package et tout ce que vous devez faire pour envoyer & email à chaque auteur d'un paquetage utile, etc.

Par exemple, si Debian (et ses dérivés: Ubuntu, etc.) est si bon, c'est que vous pouvez utiliser votre système sans problème, sans avoir à installer quoi que ce soit en dehors des dépôts, et que tout ce qu'il contient a été minutieusement testé. Les fonctionnalités réelles du gestionnaire de paquets sont importantes, mais secondaires aux paquets gérés eux-mêmes.

Synchronisation facile de la configuration : comme beaucoup de gens, j'utilise Emacs sur de nombreux ordinateurs et serveurs, qu'ils soient les miens ou non. Ce serait étonnant si le gestionnaire de paquets avait une sorte de fichier que je pouvais transférer d'un ordinateur à un autre; ensuite, sur ce dernier ordinateur, le gestionnaire de paquets amènerait mon Emacs à l'état dans lequel je l'aime bien - tous les paquets installés et les configurations définies. Combiné avec la possibilité d’installer facilement soit à l’échelle du site (si l’on dispose des autorisations root), soit en tant qu’utilisateur unique, je peux synchroniser l’ensemble d’Emacsen, où qu’il se trouve.

Je suis presque convaincu que la meilleure solution consiste à soumettre davantage de packages à ELPA et à ajouter un support multi-sources à package.el. Les responsables d'Emacs ont déclaré qu'ils envisageraient d'inclure package.el dans la version 24, à condition que celui-ci pointe par défaut sur un référentiel FSF.

Bien entendu, la soumission doit également être un processus automatisé. la méthode actuelle d'envoi du responsable ELPA ne fonctionne que sur une petite échelle.

Peu importe la façon dont cela est fait, la chose la plus importante à mon avis est qu’il devrait être trivial de soumettre des packages au référentiel. Dans le même temps, nous ne voulons pas que ces packages soient immédiatement disponibles, pour se protéger contre les codes malveillants (et en raison de problèmes de licence). Sauf s'il existe une "confiance" système en place, basé sur des signatures cryptographiques.

Aussi utile:

  • "quotients", pour installer plusieurs packages à la fois.
  • De la même manière, nous devrions pouvoir installer un ensemble de fichiers elisp pour des raisons de maintenabilité
  • " Broken " les paquets ne devraient pas être autorisés à perturber le démarrage d’Emacs. C’est facile et je l’ai implémenté dans mon propre .emacs
  • Possibilité d'installer des fichiers autres que des scripts. Ceci est souvent négligé, mais très utile. Par exemple, vous pourriez envoyer des images, des icônes, des barres d’outils, etc.
  • Gestion des versions: le package X nécessite le package Y > 1,0
  • Tests: effectuez des contrôles de base, testez les conflits (combinaisons de touches, redéfinitions de fonctions, fonctions attendues mais non présentes, etc.).
  • Suivi des bogues : je ne saurais trop insister sur l'importance de cela. Il est extrêmement important de disposer d’un emplacement centralisé pour signaler les bogues (et pouvoir les suivre) afin d’assurer la qualité des paquets.

Une sorte d'archive compressée semble être préférable pour faire partie de ce qui précède.

Jusqu'à présent, un ELPA bien amélioré semble être la voie à suivre.

J'ai déjà passé du temps à écrire un petit gestionnaire de paquets pour Emacs.

http://gmarceau.qc.ca/plugin.el

J'ai écrit:

  

Le plugin est ma tentative de créer un   gestionnaire de paquets pour Emacs. Brancher   va télécharger automatiquement Emacs   extensions, les décompresse dans un   répertoire, ajoute ce répertoire au   load-path, génère un chargement automatique   annotations, et modifiez vos dot-emacs   fichier. Les annotations à chargement automatique sont un   fonctionnalité peu connue d'Emacs. Une fois que   ils sont générés, les extensions Emacs   charger rapidement et progressivement, ce qui   c'est vraiment bien si vous en avez autant   extensions installées comme je le fais.

Vous aurez besoin de deux fichiers de bibliothèque pour l'exécuter, loop-constructs.el et record.el

Je pense que les hackers de l'iPhone sont devenus très proches de ce que je veux, tout comme celui d'ubuntu "apt".

J'aime pouvoir:

  • ajouter
  • remove (package uniquement)
  • supprimer les paramètres utilisateur
  • voir la documentation
  • mettre à niveau (après avoir lu le journal des modifications)
  • ajouter une nouvelle archive (ou ajouter un référentiel)
  • voir les dépendances
  • voir la version
  • recherche de nom, mot clé
  • parcourir par (date d'ajout, date de modification, nom)
  • enregistrez tous les packages installés & amp; paramètres
  • charger un ensemble de paquets & amp; paramètres

Je voudrais un ensemble de choses qui fonctionnent bien et qui sont la manière recommandée de faire quoi que ce soit. Ensuite, un ensemble global où tout fonctionne fonctionne. Ensuite, la possibilité pour quiconque d'héberger ses propres archives.

Ce serait bien si tout cela était lié à git / svn / que vous voulez pour pouvoir installer les anciennes versions. Créez vos propres patchs en éliminant etc etc etc

.

En plus de ce qui est mentionné ci-dessus, j'attends quelque chose comme debian et d'autres référentiels - un ensemble de paquets stables, expérimentaux et non testés. Possibilité d'ajouter mes propres référentiels - J'utilise beaucoup de packages directement à partir de VCS. Il peut donc être utile de créer mes propres packages

Je pense que le gestionnaire de paquets devrait s'inspirer beaucoup de Rubygems . Je pense également qu’il devrait avoir un site comme Gemcutter .

Un référentiel central pourrait également être intéressant (comme Emacsmirror ). Toutefois, cela peut ne pas être nécessaire s’il existe un site tel que Gemcutter qui collecte tous les packages.

Je pense que ces choses sont importantes pour que cela fonctionne.

  • Emplacement central quelconque regroupant tous les packages
  • Facile d'ajouter des packages
  • Packages faciles à gérer
  • Facile à contribuer à d'autres packages
  • Facile à installer, désinstaller et mettre à jour les packages
  • Possibilité d'ajouter des dépendances de paquets
  • Structure commune à tous les packages

Ainsi, un gestionnaire de paquets comme Rubygems avec un site comme Gemcutter et un référentiel central comme Emacsmirror (de préférence sur Github en raison de son codage social) rendrait vraiment bien à Emacs.

Tout compte fait, je pense qu’il faut tirer beaucoup d’inspiration de Rails et de la façon dont Rails traite les pierres précieuses.

Je ne sais pas à quel point cette question est fraîche ...
mais le modèle que je voudrais voir est le CPAN. Je ne connais pas non plus Rubygems, mais cela ressemble au CPAN.

CPAN est une archive Perl + système de gestion de bibliothèque. Lorsque je dois écrire un programme perl nécessitant ... FTP ou SOAP ou JSON ou XML ou ZIP, ou ... etc., je peux exécuter le gestionnaire de packages CPAN, sélectionner le package requis pour le téléchargement, afficher et vérifier les dépendances, puis installez tout. CPAN est reflété .. "partout".

CPAN fonctionne à merveille pour mes besoins et il serait bien d’avoir quelque chose de similaire pour emacs. Il prend également en charge la création de code C / C ++ à la demande.

C'est ce que j'aimerais voir dans emacs.

Quelques commentaires supplémentaires sur les exigences.

  • téléchargement explicite des packages. Aucune installation automatique. Pas de téléchargements invisibles. Je veux demander de nouvelles bibliothèques ou une nouvelle fonction.
  • Je devrais pouvoir lister le nom / la version / l'horodatage des paquets installés.
  • Si mon ami me donne sa liste, je devrais pouvoir comparer son état emacs à celui que je possède.
  • fonction de vérification des mises à jour. Quelles mises à jour sont disponibles? Que réparent-ils?
  • vérification de dépendance, vérification et téléchargement. Si j'installe csharp-mode et qu'il nécessite la version 5.0.28 du mode cc, il devrait alors confirmer avec moi que je dois également télécharger le mode cc.
  • il devrait exister une sorte de classement communautaire de ces packages, comme le classement de torrents sur isohunt. Je veux voir si un paquet a 3 votes positifs ou 3000.
  • " transactionnel " comportement. Si une installation est en plein essor, elle doit se dérouler dans un état connu pour la dernière fois.
  • échoue. Si j'ai mis des mods personnalisés dans linum.el, il devrait refuser d'installer une nouvelle version par-dessus mes modifications, à moins que je ne l'autorise explicitement. Cela devrait m'avertir avant même de commencer. Faites cela avec les sommes de contrôle / md5 sur l'installation existante.
  • ont la possibilité d’exécuter certains paquets à partir d’archives compressées, comme des fichiers zip. Je n'ai donc aucun doute sur le fait que je n'ai mis à jour aucun des elisp incorporés.
  • possibilité d'utiliser des hôtes en miroir pour la distribution de paquets.
  • toute cette fonction devrait être accessible via M-x library-manageemnt ou quelque chose du genre.

Enfin, il serait intéressant de pouvoir séparer ou organiser les bibliothèques de fonctions. Espaces de noms hiérarchiques. L'espace de noms plat d'Emacs est très daté. C'est en quelque sorte indépendant mais complémentaire à la fonction principale de la gestion des paquets. Je ne suis pas un gourou lisp, donc je ne sais pas à quel point ce serait difficile; peut-être existe-t-il déjà un moyen de le faire.

Les gestionnaires de paquets n'offrent rien de ce que j'apprécie w.r.t. Paquets elisp à fichier unique avec dépendances simples: l’ajout et la suppression de site-lisp n’ont jamais causé de problèmes. Ce sont des packages qui dépendent de programmes externes (par exemple, ispell), de packages multi-fichiers (par exemple, auctex, org-mode) qui peuvent s'avérer délicats. Vous ne pouvez imaginer aucun package elisp à fichier unique avec des dépendances non triviales, à l’avance.

Pour ceux-ci, à l'exception d'un gestionnaire de paquets, j'aimerais que les paquets elisp d'emacs acquièrent des suites de tests pouvant être exécutées en masse et fournissant des informations utiles en cas de défaillance de dépendance.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top