Antecedentes

Uso emacs diariamente, pero principalmente para hacer las cosas. Realmente no me gusta personalizarlo más que agregar paquetes y no me gusta la solución de problemas. Quiero que los emacs se desvanezcan en el fondo como lo hace un buen sistema operativo y simplemente continúen con las cosas. Hace un tiempo descubrí que eso el-getme permitía instalar los paquetes que necesitaba que no estaban disponibles package.ely también me dio más control, como seleccionar la maintrama del modo Org en lugar del borde sangriento que puede causar problemas temporales. Ahora no estoy seguro de si debería estar usando el-geto no.

Pregunta

el-getParecía ser una gran solución para los diversos repositorios y hacks de emacs que existen. Ofrecía capacidades que simplemente no eran posibles con package.el. Ahora que package.elen las versiones más recientes de emacs ( >=24.4) soporta múltiples repositorios, ¿cuáles son los casos de uso el-gety alternativas similares al administrador de paquetes incorporado de emacs?

Hay cosas que aún son imposibles con ELPA, y hay cosas que siempre serán imposibles con ELPA, porque no encajan en el concepto de ELPA: nunca podrás instalar un commit específico por su hash desde una bifurcación repositorio. Del mismo modo, nunca podrá aplicar parches locales personalizados a un paquete antes de instalarlo. Estas características simplemente están más allá del alcance de ELPA, y si las necesita, deberá usar un administrador de paquetes alternativo.

Sin embargo, creo que el-get es una especie de solución heredada hoy en día. Dado que ELPA se ha convertido en el administrador de paquetes estándar de facto para Emacs, los administradores de paquetes alternativos deberían integrarse perfectamente con ELPA. sin embargo, el-get no expone sus propios paquetes a ELPA, lo que significa que sus paquetes son completamente invisibles para ELPA y los paquetes de ELPA nunca pueden depender de los paquetes de el-get, con implicaciones obvias para la gestión de dependencias.

Si necesita funciones más allá de ELPA, ahora debería mirar QUELPA en lugar de el-get.

He escrito un nuevo administrador de paquetes para Emacs straight.el, que intenta mejorar todas las soluciones de administración de paquetes existentes. Hay una sección extensa en la straight.eldocumentación sobre comparaciones con otros administradores de paquetes , pero aquí hay un resumen muy breve:

• package.eldescarga tarballs opacos de servidores centrales, sin opción para seleccionar una versión específica de un paquete, y no le permite realizar cambios locales en sus paquetes; contribuir con los cambios aguas arriba es imposible. straight.elclona los repositorios de Git de forma descentralizada ( si lo desea, utiliza automáticamente recetas de MELPA , GNU ELPA y EmacsMirror ) y le permite realizar cambios locales arbitrarios, comprometer esos cambios y contribuir en sentido ascendente. Esto se puede hacer manualmente o puede usar las operaciones de administración de repositorio masivo incorporadas. Los cambios en sus paquetes se detectan automáticamente y no se requieren reconstrucciones manuales. Además,straight.el admite una reproducibilidad completa para su configuración de Emacs, ya que le permite escribir un archivo de bloqueo de revisión que incluye los hash Git de todos sus paquetes.
• Quelpa y Cask se basan package.ely heredan muchas de las mismas desventajas. Por ejemplo, Cask no tiene ningún concepto de instalar una versión particular de un paquete. Quelpa sí, pero requiere que codifiques el hash Git en tu archivo init. straight.elevita por package.elcompleto, reemplazando toda su funcionalidad principal con un diseño unificado adaptado a muchos más casos de uso.
• el-get tiene la ventaja de que puede instalar paquetes desde cualquier lugar (todos los sistemas de control de versiones conocidos, HTTP arbitrario, administradores de paquetes del sistema, EmacsWiki, incluso go get!?). Sin embargo, al admitir tantas fuentes, el-get no puede proporcionar el tipo de operaciones avanzadas de gestión de paquetes (como la reproducibilidad a través de archivos de revisión de revisión y operaciones de gestión de repositorio interactivas) que straight.elproporciona. straight.elsolo es compatible con Git, ya que la mayoría de los paquetes están disponibles a través de Git y los que no se pueden obtener a través de EmacsMirror (¡te reto a que encuentres uno que no puede ser!). Tenga en cuenta que, straight.elsin embargo, proporciona una API extensible para backends de control de versiones adicionales (por ejemplo, para Mercurial) que se agregarán en el futuro, si lo desea.
• Borg tiene una filosofía muy similar straight.ely ofrece muchas de las mismas ventajas. Sin embargo, no está diseñado para ser un gestor de paquetes completa, y está diseñado para ser utilizado en la preocupación con otras herramientas como epkg, auto-compiley Magit. Por el contrario, straight.eles autónomo y proporciona todo lo que necesita por sí mismo, lo que requiere poca o ninguna configuración adicional. Además, Borg utiliza submódulos Git, cuya interfaz tiene algunos bordes ásperos, mientras que straight.elutiliza repositorios Git gestionados de forma independiente, lo que proporciona flexibilidad y potencia adicionales.
• También está el enfoque manual, pero no lo recomiendo. Después de los primeros meses, habrías reinventado Borg. Luego, después de los próximos dos meses, habrías reinventado straight.el. Sin embargo, aprenderá mucho sobre la gestión de paquetes;)

Si bien hay pros y contras, creo que el-get sigue siendo relevante, a pesar de las fuertes opiniones de @lunaryon (rechazo también).

Usé raw package.el con use-package durante un tiempo (2 a 3 años), luego cambié a el-get , luego Cask . Regresé a el-get hace unos días. Anterior package.el , como muchos otros, manejaba complementos manualmente.

¿Por qué volví a el-get ? Encontré algunas rarezas de Cask sobre algo que no es un repositorio de git (un paquete mío de Github que no está en MELPA), mientras que ese paquete en realidad usa git ... No me molesté en investigar o crear un boleto, solo saqué mi viejo el-get config y estaba listo para ir en poco tiempo.

Pocas cosas que me gustan de el-get :

• Admite múltiples buscadores, no solo git.
• Contiene suficientes recetas predefinidas
• Más rápido que Cask en el inicio.
• y sí @lunaryorn, el Wiki no es un lugar para distribuir código, aún así no quiero crear un repositorio de Github si no hay clon en emacsmirror (Github).
• Autónomo, con Cask necesitas una instalación externa. Utilizo un único archivo de inicio (no una configuración modular) con modo completo para navegar por las secciones.
• el-get es lo suficientemente simple desde la perspectiva del usuario.

Nota: estoy ejecutando Emacs Git HEAD en OSX y Linux.

Es posible que desee echar un vistazo paradox. No es otro administrador de paquetes, sino un front end más ordenado package.el. Por ejemplo, cuando actualiza paquetes, le pregunta si desea instalarlos y eliminar los antiguos en un solo paso.

Si lo usa, es probable que desee conjunto paradox-execute-asynchronouslya ten su archivo de inicio.