Qu’attendez-vous d’un gestionnaire de paquets pour Emacs?

Publication automatique à partir du contrôle de version

J’aimerais voir un gestionnaire de paquets standard, central et unique d’ Emacs. En ce moment, je mettrais mon argent sur ELPA , mais le chemin est encore long.

La chose la plus importante qui aiderait un gestionnaire de paquets Emacs serait de rendre la publication des paquets extrêmement simple. À mon avis, je souhaiterais que cela se produise en combinaison avec un système de contrôle de version comme git sur une plate-forme hébergée centrale telle que GitHub – ce qui faciliterait la publication des paquets par les auteurs et faciliterait la tâche aux autres. consortingbuer en retour.

Semblable à la façon dont GitHub (autrefois) facilitait la publication de RubyGems, j’aimerais voir quelque chose de similaire dans un gestionnaire de paquets Emacs. Par exemple, étiquetez votre référentiel avec “vX.YZ” et mettez à disposition de tous vos bienfaits elisp.

L’avantage supplémentaire d’utiliser un backend populaire comme GitHub est que vous obtiendrez immédiatement beaucoup d’exposition, ce qui devrait consortingbuer à son succès.

J’apprends encore Emacs, donc je n’ai pas eu l’occasion de me pencher sur les gestionnaires de paquets, mais une excellente fonctionnalité serait d’informer l’utilisateur que le paquet est disponible s’il essaie de l’utiliser, mais pas sur son système. Par exemple, je voulais éditer un fichier PHP sur un serveur une fois, et j’ai essayé

Mx php-mode 

et Emacs était comme

 Mx php-mode [no match] 

quand ça aurait dû être comme

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

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

Ce que j’attends le plus, c’est que tout soit utile et fonctionne bien. Cela exige que vous (ou une équipe de responsables) poursuivez de manière agressive tout ce qui concerne l’emballage, et que vous fassiez tout ce qui est nécessaire pour envoyer un e-mail à chaque auteur d’un paquet utile, etc.

Par exemple, la raison pour laquelle Debian (et ses dérivés: Ubuntu, etc.) est si bonne est que vous pouvez utiliser votre système sans avoir à installer quelque chose en dehors des référentiels, et que tout ce qu’il contient est testé de manière approfondie. Les fonctionnalités réelles du gestionnaire de packages sont importantes, mais secondaires aux packages gérés eux-mêmes.

Synchronisation facile de la configuration : Comme beaucoup de gens, j’utilise Emacs sur de nombreux ordinateurs et serveurs, dont certains sont propres et d’autres non. Ce serait étonnant si le gestionnaire de paquets avait une sorte de fichier que je pouvais transférer d’un ordinateur à un autre; puis, sur ce dernier ordinateur, le gestionnaire de paquets amènerait mes Emacs dans l’état dans lequel je les aime – tous les paquets installés et les configurations définies. Combiné à la possibilité de l’installer facilement à l’échelle du site (si l’on dispose des droits d’utilisateur root) ou en tant qu’utilisateur unique, je pourrais synchroniser tout Emacsen partout.

Je suis presque certain que la meilleure solution consiste à envoyer plus de paquets à ELPA et à append un support multi-source à package.el. Les responsables d’Emacs ont déclaré qu’ils envisageraient d’inclure package.el dans la version 24, à condition que celle-ci pointe par défaut vers un repository 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 que cela devrait être sortingvial de soumettre des paquets au repository. Dans le même temps, nous ne souhaitons pas que ces packages soient instantanément disponibles, afin de se prémunir contre les codes malveillants (et les problèmes de licence). Sauf s’il existe un système de “confiance”, basé sur des signatures cryptées.

Aussi utile:

• “métapaquets”, pour installer plusieurs paquets à la fois.
• De la même manière, nous devrions pouvoir installer un ensemble de fichiers Elisp, pour la maintenabilité
• Les paquets “brisés” ne doivent pas être autorisés à perturber le démarrage d’Emacs. C’est facile et je l’ai implémenté dans mes propres .emacs
• Possibilité d’installer des fichiers autres que des scripts. Ceci est souvent négligé, mais très utile. Vous pourriez, par exemple, expédier des images, des icons, des barres d’outils, etc.
• Gestion des versions: le package X requirejs le package Y> 1.0
• Tests: effectuer des vérifications de base, tester les conflits (raccourcis, redéfinitions des fonctions, fonctions attendues mais non présentes, etc.).
• BUG TRACKING : Je ne saurais trop insister sur l’importance de cela. Il est extrêmement important d’avoir un endroit centralisé pour signaler les bogues des paquets (et être en mesure de les suivre) afin d’assurer la qualité des paquets.

Une sorte d’archive compressée semble être la meilleure pour faire certaines des choses ci-dessus.

Jusqu’à présent, une ELPA nettement améliorée semble être la voie à suivre.

Une fois, j’ai passé du temps à écrire un petit gestionnaire de paquets pour Emacs.

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

J’ai écrit:

Plugin est ma tentative de créer un gestionnaire de paquets pour Emacs. Plugin télécharge automatiquement les extensions Emacs, les décompresse dans un répertoire, ajoute ce répertoire au chemin de chargement, génère des annotations à chargement automatique et modifie votre fichier dot-emacs. Les annotations à chargement automatique sont une fonctionnalité peu connue d’Emacs. Une fois générées, les extensions d’Emacs se chargent rapidement et progressivement, ce qui est vraiment bien si vous avez installé autant d’extensions que moi.

Vous aurez besoin de deux fichiers de bibliothèque pour le faire fonctionner, loop-constructs.el et record.el

Je pense que les pirates pour l’iPhone sont assez proches de ce que je veux, tout comme le fait “apt” d’Ubuntu.

J’aime pouvoir:

• append
• retirer (paquet seulement)
• supprimer les parameters de l’utilisateur
• voir la documentation
• mise à niveau (après avoir lu le journal des modifications)
• append une nouvelle archive (aka append un repository)
• voir les dépendances
• voir la version
• recherche de nom, mot-clé
• parcourir par (date ajoutée, date de modification, nom)
• enregistrer tous les paquets et parameters installés
• ensemble de chargement de paquets et parameters

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

Ce serait bien si tout cela était lié à git / svn / ne serait-ce que pour pouvoir installer les anciennes versions. Faites vos propres patchs en vous arrêtant, etc., etc., etc.

Outre ce qui précède, j’attends quelque chose comme Debian et d’autres référentiels – ensemble des paquets stables, expérimentaux et non testés. Possibilité d’append mes propres référentiels – j’utilise beaucoup de paquets directement à partir de VCS, il pourrait donc être utile de créer mes propres paquets

Je pense que le gestionnaire de paquets devrait s’inspirer de Rubygems . Je pense aussi que cela devrait avoir un site comme Gemcutter .

Un repository central pourrait également être intéressant (comme Emacsmirror ). Cela peut ne pas être nécessaire si un site comme Gemcutter existe qui collecte tous les paquets.

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

• Emplacement central qui recueille tous les colis
• Facile à append des paquets
• Facile à entretenir les paquets
• Facile à consortingbuer à d’autres forfaits
• Facile à installer, désinstaller et mettre à jour les paquets
• Possibilité d’append des dépendances de paquet
• Structure commune pour tous les paquets

Donc, un gestionnaire de paquets comme Rubygems avec un site comme Gemcutter et un repository central comme Emacsmirror (de préférence sur Github à cause de son codage social) ferait vraiment du bien à Emacs.

Tout compte fait, je pense que Rails doit être inspiré et que Rails gère les Gemmes.

Je ne sais pas combien cette question est fraîche …
mais le modèle que j’aimerais voir est le CPAN. Je ne connais pas non plus Rubygems mais cela ressemble à CPAN.

CPAN est un système de gestion des archives et des bibliothèques Perl. Lorsque je dois écrire un programme Perl nécessitant FTP, SOAP, JSON ou XML ou ZIP, etc., je peux exécuter le gestionnaire de paquets CPAN, sélectionner le paquet requirejs 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 quelque chose de similaire pour emacs serait bien d’avoir. 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 de paquets. Pas d’installation automatique Pas de téléchargements invisibles. Je veux demander de nouvelles bibliothèques ou de nouvelles fonctions.
• Je devrais pouvoir lister le nom / version / timestamp des paquets installés.
• Si mon ami me donne sa liste, je devrais pouvoir faire le point sur son emacs contre le mien.
• fonction check-for-updates. Quelles sont les mises à jour disponibles? Qu’est-ce qu’ils réparent?
• vérification, vérification et téléchargement des dépendances. Si j’installe csharp-mode et qu’il nécessite v5.0.28 de cc-mode, alors il devrait me confirmer que je dois aussi télécharger cc-mode.
• Il devrait y avoir une sorte de classement communautaire de ces paquets, comme le classement des torrents sur isohunt. Je veux voir si un paquet a 3 relevés ou 3000.
• comportement “transactionnel”. Si une installation est en plein essor, elle doit se dérouler dans un dernier état connu.
• défaillances. Si j’ai mis des mods personnalisés dans linum.el, il devrait refuser d’installer une nouvelle version sur mes modifications, à moins que je ne l’autorise explicitement. Il devrait m’avertir avant même de commencer. Faites cela avec checksums / md5 sur l’installation existante.
• avoir la possibilité d’exécuter des paquets à partir d’archives compressées, comme les fichiers zip. Je n’ai donc aucun doute sur le fait que je n’ai mis à jour aucun des élisps embarqués.
• possibilité d’utiliser des hôtes en miroir pour la dissortingbution de packages.
• toute cette fonction devrait être accessible via Mx library-manageemnt ou quelque chose du genre.

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

Les gestionnaires de paquets n’offrent rien que j’apprécie par rapport aux paquets elisp à un seul fichier avec des dépendances simples: l’ajout et la suppression de site-lisp n’ont jamais causé de problèmes. Ce sont des paquets qui dépendent de programmes externes (par exemple, ispell), de paquets multi-fichiers (par exemple, auctex, org-mode) qui peuvent être compliqués. Vous ne pouvez pas penser à un package elisp à un seul fichier avec des dépendances non sortingviales, de manière désinvolte.

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 qui fournissent des informations utiles en cas de pannes de dépendance.