Noto que hay varios repositorios diferentes que a menudo contienen el mismo software. ¿Por qué querría preferir:
sobre los demás? Dado que cualquier repositorio no contiene todos los paquetes que quiero, ¿es una buena idea tener estos repositorios habilitados simultáneamente?
Respuestas:
GNU ELPA es el repositorio oficial de paquetes de GNU Emacs. Es el único habilitado por defecto, lo que significa que tiene el mayor alcance. Al mismo tiempo, enviar un paquete es un poco complicado y requiere una asignación de derechos de autor FSF, lo que significa que tiene una selección relativamente limitada de paquetes.
MELPA y Marmalade son repositorios de paquetes de terceros. GNU no los admite oficialmente, pero también tienen selecciones mucho más grandes de paquetes. La calidad del paquete es un poco más variable, pero es mucho más probable que encuentre lo que está buscando, especialmente si es un poco oscuro.
Marmalade y MELPA tienen modelos ligeramente diferentes para cargadores de paquetes. Según tengo entendido, MELPA rastrea un repositorio de control de versiones directamente (es decir, a través de GitHub), lo que permite a los autores de paquetes actualizar paquetes simplemente empujando commits a una rama. Marmalade, por otro lado, hace que las personas carguen paquetes al repositorio explícitamente.
En la práctica, no he visto mucha diferencia entre MELPA y Marmalade. No hay mucho inconveniente en permitir que ambos tengan la mayor selección posible de paquetes instalables: he estado usando ambos (y GNU ELPA, por supuesto) durante un tiempo sin problemas significativos.
Una posible preocupación (que no me he encontrado) con tener ambos repositorios habilitados, que no me he encontrado, es tener paquetes disponibles de ambos en diferentes versiones. Por defecto, el administrador de paquetes ( package.el) no tiene ninguna forma de resolver conflictos como este; sin embargo, puede resolver esto instalando el melpapaquete que le permite personalizar qué paquetes se proporcionan o se excluyen de qué repositorios. Puede ver más detalles aquí o en la documentación del melpapaquete.
Como @Malabarba señaló útilmente, este problema se resuelve en Emacs 24.4.
Si está realmente preocupado por la seguridad, es posible que desee evitar tanto MELPA como Marmalade porque permiten que cualquiera cargue paquetes y, que yo sepa, no tienen ningún acuerdo de seguridad proactivo. El repositorio GNU ELPA, por otro lado, es administrado por la FSF y tiene paquetes firmados que deberían ayudar. Por supuesto, si la seguridad es realmente importante, es posible que desee revisar e instalar los paquetes elisp a mano en lugar de usar el administrador de paquetes.
A mi modo de ver, algunos repos tienen más gastos generales relacionados con el envío de paquetes que otros; los repositorios con más gastos generales tienden a tener menos paquetes. En orden de mayor a menor sobrecarga:
Personalmente, creo que MELPA Stable o Marmalade probablemente ganarán a la larga para la mayoría de los usuarios: MELPA propiamente dicho es bastante inestable y ELPA es demasiado restrictivo para ser realmente escalable para muchos paquetes. Pero eso es solo una opinión.
Hay varios repositorios de paquetes disponibles.
Oficial
GNU ELPA es el repositorio oficial del paquete. Es pequeño y requiere la asignación de derechos de autor (de todos los autores de un paquete) a la FSF para contribuir a él.
Los paquetes en GNU ELPA son realmente solo un repositorio git . La ventaja de estar alojado aquí es que el equipo central intenta actualizar los paquetes si Emacs mismo agrega o desprecia las características.
Construido desde la fuente
MELPA es el repositorio de paquetes más grande y de más rápido crecimiento . Lanza una nueva versión cada vez que se empuja una nueva versión a un repositorio, o se actualiza una página de EmacsWiki.
Es sangrienta, pero funciona muy bien en la práctica. MELPA está curada para evitar paquetes duplicados y para garantizar que se registre el inicio canónico del paquete (en lugar de una bifurcación aleatoria).
MELPA tiene el problema de que las versiones son solo marcas de tiempo, por ejemplo my-package-20131231.2359. Esto significa que si depende de my-package:
;; Package-Requires: ((my-package "1.2.3"))
entonces Emacs pensará que cualquier versión de MELPA es lo suficientemente nueva.
MELPA Stable es lo mismo que MELPA, pero en lugar de usar versiones de fecha y hora, usa las versiones en etiquetas git. Esto permite una mejor resolución de dependencia, pero tiene problemas para depender de los paquetes wiki .
Subidas de usuarios
Marmalade es mucho más como un repositorio tradicional de otros lenguajes de programación. El desarrollador del paquete carga el paquete a Marmalade cuando hacen un lanzamiento.
En principio, esto le da a los paquetes un proceso de lanzamiento adecuado (Marmalade es anterior a MELPA estable) y también evita el problema del número de versión autogenerado. Sin embargo, no hay verificación de identidad. Cualquiera puede cargar un paquete, incluso si no lo escribió. Esto se vuelve difícil si el responsable de mantenimiento my-packageencuentra que alguien más ha subido my-packagey no puede cargar nuevas versiones posteriormente.
Marmalade solía ser una aplicación node.js, y ahora está escrita en elisp. Ambas versiones han tenido problemas de tiempo de actividad ocasionalmente.
Proyecto específico
Org-mode ELPA es un repositorio que solo aloja orgy org-plus-contrib. Org-mode es parte del núcleo de Emacs, pero está desarrollado externamente y el código solo se sincroniza periódicamente con el enlace troncal de Emacs. Este repositorio le permite tener el modo org de vanguardia.
User42 ELPA es un repositorio para un desarrollador de paquete único que ha lanzado una gran variedad de paquetes de Emacs . Si le gusta alguno de sus paquetes, puede agregar este repositorio.
Sunrise Commander ELPA es un repositorio de extensiones para Sunrise Commander (un paquete de Emacs para la exploración de archivos, inspirado en Midnight Commander ).
Retirado
El ELPA de Tromey fue el primer repositorio establecido. Se reemplaza oficialmente con GNU ELPA, pero no tenía los mismos requisitos de asignación de derechos de autor. A partir de 2010, ya no se actualiza.
El archivo de paquetes de Elpy contenía varios paquetes desarrollados por Jorgen Schaefer para 'Elpy, el entorno de desarrollo de Python de Emacs' , pero que migraron a MELPA Stable.
no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: pero estoy seguro de que esas preocupaciones desaparecerán ahora que es Microsoft GitHub ;-)
Alguna información adicional, para complementar las otras respuestas aquí.
Alguna información sobre MELPA y MELPA "estable" -
Comience mirando esta pregunta casi duplicada , de StackOverflow, incluidos los comentarios de la pregunta en sí. En particular, este comentario que publiqué, después de intercambiar correos electrónicos con Donald Curtis (responsable de MELPA y MELPA estable):
Desde su punto de vista [el de Donald Curtis, y según tengo entendido su comunicación para mí], el sitio "estable" de MELPA está en modo de mantenimiento solamente . Y la única razón por la que no existe un código como el mío es porque nadie ha implementado la carga desde la wiki [Emacs Wiki] para el sitio "estable". Además, no hay "curación" por parte de nadie: no hay filtros para determinar si un paquete es estable, arriesgado, etc. Algunos desarrolladores de paquetes solicitaron la existencia de dos sitios que querían distinguir las versiones de desarrollo de sus paquetes de las anteriores ("estable ") versiones.
En resumen, no hay nada que sea inherentemente más "estable" sobre el contenido de "MELPA estable" . La numeración de la versión y el método de alimentación pueden ser diferentes; eso es todo. Y si un mantenedor de paquete en particular quiere distinguir las versiones "estables" de las versiones de "desarrollo", y quiere hacerlo cargándolas en los dos sitios diferentes, entonces ese es el efecto para ese paquete .
Una diferencia entre MELPA y Marmalade (y GNU ELPA) es que no se requiere que el código contribuido a MELPA se obtenga de un repositorio git. En particular, se puede extraer automáticamente del Área Elisp de Emacs Wiki .
¿Significa eso, como han dicho algunos, que cualquiera puede cargar cualquier cosa y que no tiene forma de saber si el código es realmente del autor reclamado, etc.? Si y no. En general, sí: cualquiera es libre de cargar el código de Elisp a Emacs Wiki. Como dice la parte superior de la página Elisp-Area:
Esta es el área de EmacsWiki elisp, donde recopilamos archivos EmacsLisp. No se requiere inicio de sesión, no se requiere control de versión, no se requiere ftp, no se requiere contraseña. Es tan simple como la propia wiki. Eso también significa que cualquiera puede colocar código malicioso en estos archivos EmacsLisp. En caso de duda, no los use.
Sin embargo, para que lo sepas, soy administrador de la wiki, y mis propias bibliotecas de Lisp en el área de Elisp wiki son páginas bloqueadas. Eso significa que solo un administrador de wiki puede subirlos. Entonces, en este caso, puedes estar bastante seguro de que las bibliotecas mías que descargaste de MELPA o Emacs Wiki fueron cargadas por mí. Sin embargo, al igual que con todo en Internet, no hay garantía de garantía, al igual que no hay garantía con el código en sí. Como dice la propaganda de GPL en cada biblioteca de GPL:
Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin siquiera la garantía implícita de COMERCIABILIDAD o APTITUD PARA UN PROPÓSITO EN PARTICULAR. Vea la Licencia Pública General de GNU para más detalles.
HTH. Feliz pirateo.