emacs packages package-managers

¿Qué esperas de un administrador de paquetes para Emacs?



packages package-managers (12)

Aunque existen varios miles de bibliotecas Emacs Lisp, GNU Emacs, hasta la versión 24.1 no tenía un administrador de paquetes (interno).

Supongo que la mayoría de los usuarios estarían de acuerdo en que actualmente es bastante incómodo encontrar, instalar y especialmente mantener actualizadas las bibliotecas Emacs Lisp.

Páginas que hacen la vida un poco más fácil

Para versiones de Emacs anteriores a 24.1:

  • Lista de Lisp de Emacs - Problema: veo personas muertas (enlaces).
  • Emacswiki - Problema: Puede contener rastros de nueces (código malicioso).
  • Emacsmirror - El repositorio de paquetes en el que estoy trabajando. Problema: ningún administrador de paquetes lo admite de forma nativa todavía.

Algunos administradores de paquetes

No es que nadie lo haya intentado todavía. (Algunos de estos no existían cuando se hizo esta pregunta).

ACTUALIZACIÓN - package.el se incluye en GNU Emacs, comenzando con la versión 24.1

el paquete se ha incluido en el tronco de Emacs. epkg aún no está listo y tampoco está disponible actualmente. Al menos install-elisp, plugin y use-package ya no parecen mantenerse activamente.

He creado un repository git que contiene todos estos gestores de paquetes como submódulos.

Algunas utilidades que pueden ser útiles

Los administradores de paquetes podrían usar estas utilidades y / o podrían usarse para mantener un espejo de paquetes.

Discusiones sobre el tema en cuestión

La pregunta (finalmente)

Entonces, me gustaría saber de ti lo que consideras importante / no importante / suplementario, etc. en un administrador de paquetes para Emacs.

Algunas ideas

  1. Muchos paquetes (el Emacsmirror proporciona la mayor colección de paquetes disponibles, pero todavía no hay soporte explícito en ningún administrador de paquetes).
  2. Solo paquetes que han sido probados.
  3. Soporte para más de un archivo de paquete (para que las personas puedan elegir entre muchos paquetes probados).
  4. Dependencia calculada en base a las características requeridas solamente.
  5. Las dependencias tienen en cuenta versiones particulares.
  6. Solo use versiones que se hayan lanzado en sentido ascendente.
  7. Use versiones de los sistemas de control de versiones si están disponibles.
  8. Los paquetes están categorizados.
  9. Los paquetes pueden ser desinstalados y actualizados no solo instalados.
  10. Soporte para la creación de horquillas de la versión upstream de paquetes.
  11. Apoyar la publicación de estos tenedores.
  12. Soporte para elegir un tenedor
  13. Después de que los paquetes de instalación estén activados.
  14. Genera archivos de autocarga.
  15. Integración con Emacswiki (ver wikirel.el).
  16. Los usuarios pueden etiquetar, comentar, etc. paquetes y compartir esa información.
  17. Solo software asignado por FSF / GPL / FOSS o no se preocupe por la licencia.
  18. El administrador de paquetes debe integrarse para ser distribuido con Emacs.
  19. Soporte para contactar fácilmente al autor.
  20. Montones de metadatos
  21. Sugerir alternativas antes de instalar un paquete en particular.

Estoy esperando este tipo de respuestas

  • Punteros a más implementaciones, discusiones, etc.
  • Largas descripciones de un conjunto de características que conforman su administrador de paquetes ideal.
  • Descripciones de una característica particular deseada / no deseada. Siéntase libre de elaborar sobre mis ideas desde arriba.
  • Sorpréndeme.

Además de lo mencionado anteriormente, espero algo como debian y otros repositorios: conjunto de paquetes estables, experementales y no probados. Posibilidad de agregar mis propios repositorios: uso muchos de los paquetes directamente desde VCS, por lo que podría ser útil crear mis propios paquetes


Creo que el administrador del paquete debería inspirarse en Rubygems . También creo que debería tener un sitio como Gemcutter .

Un repositorio central también podría ser bueno (como Emacsmirror ). Sin embargo, esto puede no ser necesario si existe un sitio como Gemcutter que recoge todos los paquetes.

Creo que estas cosas son importantes para que esto funcione.

  • Ubicación central de algún tipo que recolecta todos los paquetes
  • Fácil de agregar paquetes
  • Paquetes fáciles de mantener
  • Fácil de contribuir a otros paquetes
  • Fácil de instalar, desinstalar y actualizar paquetes
  • Posibilidad de agregar dependencias de paquetes
  • Estructura común para todos los paquetes

Entonces, un administrador de paquetes como Rubygems con un sitio como Gemcutter y un repositorio central como Emacsmirror (preferiblemente en Github debido a su codificación social) haría Emacs realmente bueno.

En general, creo que mucha inspiración debería tomarse de Rails y cómo Rails maneja Gems.


Creo que los hackers para el iPhone se acercaron bastante a lo que deseo, al igual que el "apt" de Ubuntu.

Me gusta ser capaz de:

  • añadir
  • eliminar (solo paquete)
  • eliminar la configuración del usuario
  • ver documentación
  • actualización (después de leer el registro de cambios)
  • agregar nuevo archivo (también conocido como agregar repositorio)
  • ver dependencias
  • ver versión
  • buscar nombre, palabra clave
  • navegar por (fecha de agregado, fecha de modificación, nombre)
  • guardar todos los paquetes instalados y configuraciones
  • cargar conjunto de paquetes y configuraciones

Me gustaría un conjunto principal de cosas que funcionan bien y son la forma recomendada de hacer lo que sea. Luego, un conjunto global donde todo lo que ingresa funciona. Luego, la capacidad de cualquier persona para alojar su propio archivo.

Sería bueno si todo esto estuviera ligado a git / svn / lo que sea para que puedas instalar versiones antiguas. Haga sus propios parches bifurcando, etc, etc ...


Estoy casi seguro de que la mejor solución es enviar más paquetes a ELPA y agregar soporte de múltiples fuentes a package.el. Los mantenedores de Emacs han dicho que considerarían incluir package.el en la versión 24 siempre y cuando apuntara a un repositorio de FSF por defecto.

Por supuesto, la presentación también debe ser un proceso automatizado; el método actual de enviar por correo el mantenedor de ELPA solo funciona a pequeña escala.


Lo que más espero es que todo lo útil esté ahí y funcione bien. Esto requiere que usted (o un equipo de encargados de mantenimiento) persiga agresivamente el empaquetado de todo por él y haga lo que sea necesario, enviando un correo electrónico a cada autor de un paquete útil, y así sucesivamente.

Por ejemplo, el motivo por el que Debian (y sus derivados: Ubuntu etc.) es tan bueno es que puede utilizar su sistema sin tener que instalar algo fuera de los repositorios, y todo lo que se encuentra en él se prueba a fondo. Las características reales del administrador de paquetes son importantes, pero son secundarias a los paquetes administrados.


Los gestores de paquetes no ofrecen nada que yo valore los paquetes elisp de un solo archivo con dependencias simples: agregar y eliminar desde site-lisp nunca ha causado problemas. Son paquetes que dependen de programas externos (por ejemplo, ispell), paquetes de varios archivos (por ejemplo, auctex, org-mode) que pueden ser complicados. No se puede pensar en ningún paquete elisp de un solo archivo con dependencias no triviales, de forma manual.

Para estos, a falta de un administrador de paquetes, me gustaría que los paquetes elisp de emacs adquieran suites de prueba que se pueden ejecutar en masa y que brindan información útil en caso de fallas de dependencia.


No importa cómo se hace esto, lo más importante en mi opinión es que debería ser trivial enviar paquetes al repositorio. Al mismo tiempo, no queremos que esos paquetes estén disponibles al instante, para protegerse contra códigos maliciosos (y debido a problemas de licencia). A menos que exista un sistema de "confianza" en su lugar, basado en firmas criptográficas.

También es útil:

  • "metapaquetes", para instalar varios paquetes a la vez.
  • De la misma manera, deberíamos poder instalar un conjunto de archivos elisp, para la mantenibilidad
  • No se debe permitir que los paquetes "rotos" interrumpan el inicio de Emacs. Esto es fácil y lo tengo implementado en mi propio .emacs
  • Posibilidad de instalar archivos que no sean secuencias de comandos. Esto a menudo se pasa por alto, pero es muy útil. Podrías, por ejemplo, enviar imágenes, iconos, barras de herramientas, etc.
  • Versiones: el paquete X requiere el paquete Y> 1.0
  • Prueba: realice comprobaciones de cordura básicas, pruebas de conflictos (combinaciones de teclas, redefiniciones de funciones, funciones que se espera que estén presentes pero no, etc.).
  • SEGUIMIENTO DE ERRORES : No puedo enfatizar la importancia de esto lo suficiente. Tener un lugar centralizado para reportar errores en los paquetes (y poder rastrearlos) es extremadamente importante para asegurar la calidad de los paquetes.

Algún tipo de archivo comprimido parece ser el mejor para hacer algo de lo anterior.

Hasta ahora, un ELPA mejorado parece ser el camino a seguir.


No sé cuán fresca es esta pregunta ...
pero el modelo que me gustaría ver es CPAN. Tampoco sé Rubygems, pero suena similar a CPAN.

CPAN es un archivo perl + sistema de gestión de biblioteca. Cuando necesito escribir un programa perl que requiera ... FTP o SOAP o JSON o XML o ZIP, o ... etc., puedo ejecutar el administrador de paquetes CPAN, seleccionar el paquete requerido para descargar, ver y verificar las dependencias, luego instala todo. CPAN se refleja en "todos lados".

CPAN funciona maravillosamente para mis propósitos, y algo similar para emacs sería bueno tener. También es compatible con la creación de código C / C ++ a pedido.

Eso es lo que me gustaría ver en emacs.

Algunos comentarios adicionales sobre los requisitos.

  • descarga explícita de paquetes. Sin instalación automática. Sin descargas invisibles. Quiero pedir nuevas bibliotecas o nuevas funciones.
  • Debería poder enumerar el nombre / versión / marca de tiempo de los paquetes instalados.
  • Si mi amigo me da su lista, debería ser capaz de diferir su estado de emacs contra el mío.
  • función de verificación de actualizaciones. ¿Qué actualizaciones hay disponibles? ¿Qué arreglan?
  • verificación de la dependencia, verificación y descarga. Si instalo csharp-mode y requiere v5.0.28 de cc-mode, entonces debería confirmar conmigo que también debo descargar cc-mode.
  • debería haber algún tipo de clasificación comunitaria de estos paquetes, como ranking de torrentes en isohunt. Quiero ver si un paquete tiene 3 votaciones ascendentes o 3000.
  • comportamiento "transaccional". Si una instalación se dispara, debe desenrollarse hasta el último estado conocido.
  • failsafes. Si he puesto modificaciones personalizadas en linum.el, debería negarse a instalar una nueva versión sobre mis cambios, a menos que lo permita explícitamente. Debería advertirme antes incluso de comenzar. Haga esto con checksums / md5 sobre la instalación existente.
  • tiene la opción de ejecutar algunos paquetes desde archivos comprimidos, como archivos zip. Así que no tengo ninguna duda de que no he actualizado ninguno de los elisp embebido.
  • capacidad de usar hosts duplicados para la distribución de paquetes.
  • toda esta función debería ser accesible a través de Mx library-manageemnt o algo así.

Finalmente, sería bueno tener una forma de segregar u organizar bibliotecas de funciones. Espacios de nombres jerárquicos. El espacio de nombres plano de Emacs es muy anticuado. Esto es una especie de independiente pero complementario a la función central de la administración de paquetes. No soy un guru de lisp, así que no sé qué tan difícil sería esto; tal vez ya hay una forma de hacerlo.


Todavía estoy aprendiendo Emacs, por lo que no he tenido la oportunidad de buscar administradores de paquetes, pero una gran característica sería informar al usuario que el paquete está disponible si intentan usarlo, pero no está en su sistema. Por ejemplo, quería editar un archivo PHP en un servidor una vez, y lo intenté

M-x php-mode

y Emacs era todo como

M-x php-mode [no match]

cuando debería haber sido como

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

y luego se habría instalado y cargado php-mode para mí. Eso habría hecho mi día allí mismo.


Una vez pasé un tiempo escribiendo un pequeño administrador de paquetes para Emacs.

plugin.el

Escribí:

El plugin es mi intento de crear un administrador de paquetes para Emacs. El complemento descargará automáticamente las extensiones de Emacs, las desempaqueta en un directorio, agrega ese directorio a la ruta de carga, genera anotaciones de carga automática y modifica su archivo de puntos emacs. Las anotaciones de carga automática son una característica poco conocida de Emacs. Una vez que se generan, las extensiones de Emacs se cargan rápida e incrementalmente, lo cual es realmente bueno si tiene tantas extensiones instaladas como yo.

Necesitará dos archivos de biblioteca para ejecutarlo, loop-constructs.el y record.el


Fácil sincronización de la configuración : Yo, como muchas personas, uso Emacs en muchas computadoras y servidores diferentes, algunos de ellos míos y otros no. Sería increíble si el administrador del paquete tuviera algún tipo de archivo que pudiera transferir de una computadora a otra; luego, en la última computadora, el administrador del paquete colocaría mis Emacs en el estado en el que me gusta: todos los paquetes instalados y las configuraciones establecidas. Combinado con la capacidad de poder instalar fácilmente todo el sitio (si uno tiene permisos de root) o como un solo usuario, podría sincronizar todo Emacsen en todas partes.


Publicación automática desde control de versión

Me encantaría ver un administrador de paquetes Emacs estándar, central y único . En este momento, pondría mi dinero en package.el , pero todavía hay un largo camino por recorrer.

Lo más importante que ayudaría a un administrador de paquetes de Emacs sería hacer súper trivial publicar paquetes. En mi opinión, me gustaría ver que esto suceda en combinación con un sistema de control de versiones como git en una plataforma central alojada como GitHub , algo que facilitaría a los autores publicar sus paquetes y facilitaría a otros contribuir de nuevo

De forma similar a como GitHub (solía) facilitar la publicación de RubyGems, me gustaría ver algo similar en un administrador de paquetes de Emacs. Por ejemplo, etiquete su repositorio con "vX.YZ" y tenga su bondad elisp automáticamente disponible para todos.

El beneficio adicional de utilizar un backend popular como GitHub es que obtendría mucha exposición inmediatamente lo que debería ayudar a impulsar su éxito.