Pregunta

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 las bibliotecas actualizadas de Emacs Lisp.

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

Para versiones de Emacs anteriores a 24.1:

  • Lista Emacs Lisp - Problema: I ver personas muertas (enlaces).
  • Emacswiki - Problema: puede contener trazas 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 está incluido en GNU Emacs, comenzando con la versión 24.1


El paquete

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

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

Algunas utilidades que podrían ser útiles

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

Debates sobre el tema en cuestión

La pregunta (finalmente)

Entonces, me gustaría saber de usted lo que considera importante / sin importancia / complementario, etc. en un administrador de paquetes para Emacs.

Algunas ideas

  1. Muchos paquetes (el Emacsmirror proporciona la mayor colección disponible de paquetes, pero no hay soporte explícito en ninguno administrador de paquetes todavía).
  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 solo en función de las características requeridas.
  5. Las dependencias tienen en cuenta versiones particulares.
  6. Utilice solo versiones que se hayan lanzado en sentido ascendente.
  7. Utilice versiones de sistemas de control de versiones si están disponibles.
  8. Los paquetes están categorizados.
  9. Los paquetes se pueden desinstalar y actualizar, no solo instalar.
  10. Admite la creación de una bifurcación de la versión ascendente de los paquetes.
  11. Soporte para publicar estos tenedores.
  12. Soporte para elegir un tenedor.
  13. Después de que se activen los paquetes de instalación.
  14. Generar archivos de carga automática.
  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 me importa la licencia.
  18. El administrador de paquetes debe integrarse, distribuirse con Emacs.
  19. Soporte para contactar fácilmente al autor.
  20. Muchos metadatos.
  21. Sugerir alternativas antes de instalar un paquete en particular.

Espero este tipo de respuestas

  • Punteros a más implementaciones, discusiones, etc.
  • Descripciones extensas de un conjunto de características que conforman su administrador de paquetes ideal.
  • Descripciones de una característica particular deseada / no deseada
¿Fue útil?

Solución

Publicación automática desde el control de versiones

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

Lo más importante que ayudaría a un administrador de paquetes de Emacs sería hacerlo súper trivial para 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 la publicación de sus paquetes y facilitaría la contribución de otros.

Similar a cómo 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.Y.Z " y tenga su bondad elisp automáticamente disponible para todos.

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

Otros consejos

Todavía estoy aprendiendo Emacs, así 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 intenta 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 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 me habría instalado y cargado el modo php. Eso habría hecho mi día allí mismo.

Lo que más espero es que todo sea útil y funcione bien. Esto requiere que usted (o un equipo de mantenedores) busque agresivamente empaquetar todo para ello y haga lo que sea que implique & # 8212; & nbsp; enviar por correo electrónico a cada autor de un paquete útil, y así sucesivamente.

Por ejemplo, la razón por la que Debian (y sus derivados: Ubuntu, etc.) es tan buena es que usted puede usar su sistema felizmente sin tener que instalar algo fuera de los repositorios, y que todo en él se prueba a fondo. Las características reales del administrador de paquetes son importantes, pero secundarias a los paquetes administrados mismos.

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

Estoy casi seguro de que la mejor solución consiste en 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 apunten a un repositorio FSF por defecto.

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

No importa cómo se haga 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 proteger contra el código malicioso (y debido a problemas de licencia). A menos que haya un " trust " sistema en su lugar, basado en firmas criptográficas.

También útil:

  • " metapackages " ;, para instalar varios paquetes a la vez.
  • Del mismo modo, deberíamos poder instalar un conjunto de archivos elisp, para mantenerlo
  • " Roto " No se debe permitir que los paquetes interrumpan el inicio de Emacs. Esto es fácil y lo tengo implementado en mi propio .emacs
  • Capacidad para instalar archivos que no sean scripts. Esto a menudo se pasa por alto, pero es muy útil. Podrías, por ejemplo, enviar imágenes, íconos, barras de herramientas, etc.
  • Versiones: el paquete X requiere el paquete Y > 1.0
  • Pruebas: realice comprobaciones básicas de cordura, pruebas de conflictos (combinaciones de teclas, redefiniciones de funciones, funciones que se espera que estén presentes pero no lo están, etc.).
  • SEGUIMIENTO DE ERRORES : No puedo enfatizar la importancia de esto lo suficiente. Tener un lugar centralizado para informar errores de 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 mucho mejor parece ser el camino a seguir.

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

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

Escribí:

  

Plugin es mi intento de crear un   gestor de paquetes para Emacs. Enchufar   descargará automáticamente Emacs   extensiones, las descomprime en un   directorio, agrega ese directorio al   ruta de carga, genera carga automática   anotaciones y modifique sus dot-emacs   expediente. Las anotaciones de carga automática son un   característica poco conocida de Emacs. Una vez   se generan, extensiones de Emacs   cargar de forma rápida e incremental, que   es realmente agradable si tienes tantos   extensiones instaladas como lo hago.

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

Creo que los piratas informáticos para el iPhone se acercaron bastante a lo que quiero, al igual que el "apt" de Ubuntu.

Me gusta poder:

  • agregar
  • 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
  • búsqueda de nombre, palabra clave
  • navegar por (fecha de adición, fecha de modificación, nombre)
  • guardar todos los paquetes instalados & amp; ajustes
  • cargar conjunto de paquetes & amp; ajustes

Me gustaría un conjunto principal de cosas que funcionen bien y que sean la forma recomendada de hacer lo que sea. Luego, un conjunto global donde todo funciona. Luego, la posibilidad de que cualquiera pueda alojar su propio archivo.

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

Además de lo mencionado anteriormente, espero algo como Debian y otros repositorios: conjunto de paquetes estables, experimentales 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 de paquetes debería inspirarse mucho 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 recopila todos los paquetes.

Creo que estas cosas son importantes para que esto funcione.

  • Ubicación central de algún tipo que recopila todos los paquetes
  • Paquetes fáciles de agregar
  • 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 a Emacs realmente bueno.

En general, creo que se debe tomar mucha inspiración de Rails y cómo Rails maneja las gemas.

No sé qué tan fresca es esta pregunta ...
pero el modelo que me gustaría ver es CPAN. Tampoco conozco Rubygems, pero suena similar a CPAN.

CPAN es un sistema de gestión de archivo + biblioteca perl. Cuando necesito escribir un programa perl que requiere ... 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 todas partes ''.

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

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

Algunos comentarios adicionales sobre los requisitos.

  • descarga explícita de paquetes. No hay instalación automática. No hay 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 poder diferenciar su estado de emacs contra el mío.
  • función de verificación de actualizaciones. ¿Qué actualizaciones hay disponibles? ¿Qué arreglan?
  • comprobación, verificación y descarga de dependencias. 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 la clasificación de torrents en isohunt. Quiero ver si un paquete tiene 3 votos a favor o 3000.
  • " transaccional " comportamiento. Si una instalación se dispara, debe relajarse a un último estado bueno conocido.
  • a prueba de fallos. Si puse mods personalizados 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 incluso antes de comenzar. Haga esto con sumas de comprobación / md5 sobre la instalación existente.
  • tiene la opción de ejecutar algunos paquetes desde archivos comprimidos, como archivos zip. Así que nunca tengo ninguna duda de que no he actualizado ninguno de los incrustados elisp.
  • capacidad de usar hosts duplicados para la distribución de paquetes.
  • toda esta función debe ser accesible a través de M-x 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 está muy anticuado. Esto es algo independiente pero complementario de la función central de la gestión de paquetes. No soy un gurú de lisp, así que no sé lo difícil que sería; tal vez ya haya una manera de hacerlo.

Los administradores de paquetes no ofrecen nada que valoro w.r.t. paquetes elisp de un solo archivo con dependencias simples: agregar y eliminar de 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 me ocurre ningún paquete de elisp de un solo archivo con dependencias no triviales, de improviso.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top