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?
fuente
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.
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
fuente