¿Consideraciones técnicas para que los mantenedores de paquetes no usen el administrador de paquetes Emacs?

Estoy notando que algunos mantenedores de paquetes notables están eligiendo no usar el sistema de administración de paquetes Emacs (ESS?) O quejándose de sus limitaciones (Helm).

Citando el archivo README.md de Helm :

ADVERTENCIA : Debido a un mal concepto de package.el que se encarga de recuperar los archivos de timón y compilarlos, los usuarios tuvieron errores la mayor parte del tiempo al actualizar desde melpa y list-package. Para evitar esto, se ha agregado Async como dependencia de helm para forzar package.el compilando sus archivos en un entorno limpio. Las personas que instalen desde git y usen el archivo make no sufrirán este problema y no necesitarán Async, aunque se recomienda ya que repara la instalación de todos los demás paquetes que puede instalar con package.el de (m) elpa. Consulte las preguntas frecuentes para obtener más información.

¿Qué limitaciones técnicas exactas tiene el sistema actual de administración de paquetes a las que podrían estar aludiendo, y por qué los paquetes deben usarse asynccomo una dependencia?

package package-repositories ess

— Amelio Vazquez-Reina
fuente

Esta pregunta debería cerrarse como demasiado amplia para este sitio, creo. Está mejor dirigido a un foro de discusión. Pruebe help-gnu-emacs@gnu.org o emacs-devel@gnu.org o Emacs reddit o algo así. " ¿Cuál es el problema exactamente? " Asume que existe uno de esos problemas, y preguntar cuáles son los posibles problemas para cualquier paquete (o cualquier mantenedor de paquetes) es demasiado amplio.

— Dibujó

ESS está alojado en Melpa: melpa.org/#/ess , tal vez sea solo una cuestión de documentación. Conozco muchos proyectos, que generalmente se pueden instalar a través de un administrador de paquetes del sistema, pero elijo no mencionar esa opción sin ninguna razón real (tal vez suponiendo que si fue tan lejos como descargar las fuentes / binarios del sitio, entonces debe tener un razón para hacerlo). No sé qué problema tuvo Helm.

— wvxvw

Tu título me parece un poco extraño. ¿Querías escribir "gerentes" dos veces o te referías a mantenedores?

— Malabarba

Escribiendo como desarrollador de ESS, háganos saber cómo podemos mejorar las cosas. Como otros han comentado, ESS está en MELPA.

— Stephen Eglen

Respuestas:

El problema al que te refieres es probablemente que cuando actualizas un paquete desde una sesión de Emacs donde ese paquete ya está en uso, la versión anterior del paquete a veces interferirá durante la compilación de la nueva versión, lo que conducirá a archivos mal compilados.

Hay una solución provisional para eso en Emacs-25, pero AFAIK el problema todavía está presente en 24.5.

— Stefan
fuente

Con la notable excepción de ProofGeneral, no conozco ningún paquete importante de Emacs que no esté disponible en algunos archivos ELPA. Específicamente, ESS está en MELPA desde hace tres años . Y PG es una historia en sí misma, y definitivamente no es representativa de todo el ecosistema de Emacs.

ELPA seguramente tiene sus defectos, pero para la gran mayoría de los paquetes funciona bien, incluso para los grandes como Magit. Helm es el único paquete que veo quejándose de ELPA. No estoy seguro de qué se quejan exactamente, pero supongo que se trata de compilar:

Durante las actualizaciones, Emacs compila la nueva versión del paquete en un entorno donde la versión anterior todavía está cargada. Normalmente, esto no hace ningún daño, pero puede romper macros en ciertas situaciones. Emacs compilar la nueva versión en contra de la antigua aplicación de la macro, lo que puede causar la rotura si el nuevo código se basa en un cambio específico en esa macro.

Sin embargo, al ser un mantenedor de paquetes, estoy bastante en desacuerdo con esta afirmación. Tiendo a culpar a Helm en lugar de a ELPA o Emacs. En mi opinión, la afirmación es una hipérbole, y el problema es un síntoma de macros que usan demasiado y ab.

Si usa muchas macros y, lo que es peor, coloca código no trivial en el cuerpo de las macros, simplemente debe tener en cuenta las implicaciones que esto tiene para la compilación de bytes y debe tener cuidado de mantener la compatibilidad con sus propias macros. dentro de su paquete. No hacerlo, y en lugar de echarle la culpa, no es algo muy agradable de hacer. Mis 2 centavos

— Lunaryorn
fuente

FWIW, no estoy de acuerdo con su desacuerdo: si bien estoy de acuerdo en que es mejor tratar de evitar el uso excesivo de macros, los problemas de compilación son reales y pueden afectar más que las llamadas de macro (por ejemplo, pueden afectar a las funciones inlinable o a las funciones llamadas durante la macroexpansión). Y cuando este problema lo muerde, sus archivos .elc son incorrectos y pueden comportarse mal de todo tipo de formas interesantes, por lo que puede ser difícil diagnosticar el problema y solucionarlo requiere desinstalar + reinstalar el paquete (una vez que haya calculado el problema y qué paquete necesita ser reinstalado.

— Stefan

@ Stefan No niego los problemas de compilación. Me mordí a mí mismo. Pero no me gusta la actitud que brilla a través de esta declaración, y la falta de lo que yo llamaría un "punto de vista equilibrado". Helm se mordió tan mal porque también cometieron muchos errores de su parte, pero su declaración no lo reconoce. En mi humilde opinión, llamar a funciones en macro cuerpo es un gran error. Las macros son solo para sintaxis, pero nunca para funcionalidad. Pero entiendo que este parece ser un tema sobre el cual la comunidad Emacs Lisp tiene muchas opiniones diferentes.

— lunaryorn

ropemacs , jdee-emacs y excorporate son paquetes notables que no están en ningún archivo ELPA (según sus criterios para los paquetes principales). Sin embargo, la gran mayoría de los paquetes son.

— Wilfred Hughes