Quais são as diferenças práticas entre os vários Repositórios de Pacotes Emacs?

Percebo que existem vários repositórios diferentes que geralmente contêm o mesmo software. Por que eu gostaria de preferir:

• GNU ELPA
• Marmelada
• MELPA

sobre os outros? Como qualquer repositório não contém todos os pacotes que eu quero, é uma boa ideia ativar esses repositórios simultaneamente?

O GNU ELPA é o repositório oficial do pacote GNU Emacs. É o único ativado por padrão, o que significa que tem o maior alcance. Ao mesmo tempo, enviar um pacote é um pouco complicado e requer uma atribuição de direitos autorais da FSF, o que significa que ele possui uma seleção relativamente limitada de pacotes.

MELPA e Marmalade são repositórios de pacotes de terceiros. Eles não são oficialmente suportados pelo GNU, mas também têm seleções muito maiores de pacotes. A qualidade do pacote é um pouco mais variável, mas é muito mais provável que você encontre o que procura, especialmente se for um pouco obscuro.

Marmalade e MELPA têm modelos ligeiramente diferentes para uploaders de pacotes. Meu entendimento é que o MELPA rastreia um repositório de controle de versão diretamente (ou seja, via GitHub), permitindo que os autores do pacote atualizem pacotes apenas pressionando commits para uma ramificação. O Marmalade, por outro lado, faz com que as pessoas enviem pacotes para o repositório explicitamente.

Na prática, não vi muita diferença entre MELPA e Marmalade. Não há muita desvantagem em permitir que os dois tenham a maior seleção possível de pacotes instaláveis: estou usando os dois (e o GNU ELPA, é claro) há um tempo sem problemas significativos.

Uma possível preocupação (que eu ainda não encontrei) em ter os dois repositórios ativados, e que não encontrei em mim mesmo, é ter pacotes disponíveis em ambos em versões diferentes. Por padrão, o gerenciador de pacotes ( package.el) não tem como resolver conflitos como este; no entanto, você pode resolver isso instalando o melpapacote que permite personalizar quais pacotes são fornecidos ou excluídos de quais repositórios. Você pode ver mais detalhes aqui ou na documentação do melpapacote.

Como o @Malabarba apontou, este problema foi resolvido no Emacs 24.4.

Se você está realmente preocupado com a segurança, evite o MELPA e o Marmalade porque eles permitem que qualquer pessoa faça o upload de pacotes e, até onde eu saiba, não tenha nenhum acordo de segurança proativo. O repositório GNU ELPA, por outro lado, é gerenciado pela FSF e assinou pacotes que devem ajudar. Obviamente, se a segurança é realmente importante, você pode revisar e instalar os pacotes elisp manualmente, em vez de usar o gerenciador de pacotes.

Na minha opinião, alguns repositórios têm mais sobrecarga no envio de pacotes do que outros; os repositórios com mais sobrecarga tendem a ter menos pacotes. Na ordem do mais ao menos sobrecarga:

1. O GNU ELPA exige que todo o código seja GPL e os direitos autorais sejam atribuídos à FSF. O código ELPA é essencialmente "propriedade" da equipe principal do Emacs, então há muito menos do que em outros repositórios. (o modo org possui seu próprio repositório, mas possui o mesmo modo de operação.)
2. O Marmalade exige que todo o código tenha uma licença compatível com GPL e que todos os pacotes sejam carregados manualmente. A propriedade é um pouco não especificada e a alteração da propriedade não tem um processo definido AFAIK.
3. O MELPA Stable está mais ou menos em concorrência direta com o Marmalade, exceto que não possui restrições de licença e cria pacotes automaticamente a partir de repositórios git usando a revisão mais recente. A propriedade é determinada por meio do repositório MELPA (alterações de propriedade ocorrem por solicitação de recebimento ).
4. O MELPA é como o MELPA estável, exceto que sempre extrai da última revisão no ramo principal de um repositório git. Os pacotes tendem a ser "de ponta", e pode ser um pouco livre para todos em termos de estabilidade (que tem prós e contras).

Pessoalmente, acho que MELPA Stable ou Marmalade provavelmente vencerão a longo prazo para a maioria dos usuários - o MELPA propriamente dito é bastante instável e o ELPA é muito restritivo para ser realmente escalável para muitos pacotes. Mas isso é apenas uma opinião.

Existem vários repositórios de pacotes disponíveis.

Oficial

GNU ELPA é o repositório oficial de pacotes. É pequeno e requer a atribuição de direitos autorais (de todos os autores de um pacote) para a FSF para contribuir com ele.

Pacotes no GNU ELPA são realmente apenas um repositório git . A vantagem de ser hospedado aqui é que a equipe principal tenta atualizar pacotes se o próprio Emacs adicionar ou descontinuar recursos.

Construído a partir da fonte

MELPA é o maior e mais rápido repositório de pacotes. Ele lança uma nova versão toda vez que uma nova versão é enviada para um repositório ou uma página do EmacsWiki é atualizada.

É uma vantagem, mas funciona muito bem na prática. O MELPA é organizado para evitar pacotes duplicados e para garantir que a casa canônica do pacote seja registrada (em vez de um fork aleatório).

O MELPA tem o problema de que as versões são apenas timestamps, por exemplo my-package-20131231.2359. Isso significa que se você depende do meu pacote:

;; Package-Requires: ((my-package "1.2.3"))

então o Emacs pensará que qualquer versão do MELPA é nova o suficiente.

MELPA Estável é o mesmo que MELPA, mas, em vez de usar versões de data e hora, ele usa as versões nas tags git. Isso permite uma melhor resolução de dependência, mas tem problemas com a dependência dos pacotes wiki .

Uploads de usuários

Marmalade é muito mais como um repositório tradicional de outras linguagens de programação. O desenvolvedor do pacote faz o upload do pacote para o Marmalade quando ele faz um lançamento.

Em princípio, isso fornece aos pacotes um processo de liberação adequado (o Marmalade é anterior ao MELPA estável) e também evita o problema do número de versão gerado automaticamente. No entanto, não há verificação de identidade. Qualquer pessoa pode fazer upload de um pacote, mesmo que não o tenha escrito. Isso fica difícil se o mantenedor de my-packagedescobrir que outra pessoa enviou my-packagee não pode posteriormente carregar novas versões.

O Marmalade costumava ser um aplicativo node.js. Agora está escrito em elisp. Ambas as versões tiveram problemas de tempo de atividade ocasionalmente.

Projeto específico

O ELPA em modo de organização é um repositório que apenas hospeda orge org-plus-contrib. O modo organizacional faz parte do núcleo do Emacs, mas é desenvolvido externamente e o código é sincronizado apenas com o tronco do Emacs periodicamente. Esse repositório permite que você tenha o modo organizacional de ponta.

O User42 ELPA é um repositório para um único desenvolvedor de pacotes que lançou diversos pacotes do Emacs . Se você gosta de algum dos pacotes dele, pode adicionar este repositório.

O Sunrise Commander ELPA é um repositório de extensões para o Sunrise Commander (um pacote Emacs para navegação de arquivos, inspirado no comandante da meia-noite).

Aposentado

O ELPA da Tromey foi o primeiro repo criado. Ele foi oficialmente substituído pelo GNU ELPA, mas não tinha os mesmos requisitos de atribuição de direitos autorais. A partir de 2010, ele não é mais atualizado.

O arquivo de pacotes Elpy continha vários pacotes desenvolvidos por Jorgen Schaefer para 'Elpy, o Emacs Python Development Environment' , mas que foi migrado para o MELPA Stable.

Algumas informações adicionais, para complementar as outras respostas aqui.

1. Algumas informações sobre MELPA e MELPA "estável" -

   Comece examinando essa pergunta praticamente duplicada , no StackOverflow, incluindo os comentários da própria pergunta. Em particular, este comentário que publiquei, depois de trocar e-mails com Donald Curtis (mantenedor do MELPA e do MELPA estável):

   Do seu ponto de vista [de Donald Curtis, e como eu entendo sua comunicação comigo], o site "estável" MELPA está apenas no modo de manutenção . E a única razão pela qual código como o meu não existe é que ninguém implementou o upload do wiki [Emacs Wiki] para o site "stable". Além disso, ninguém faz "curadoria" de ninguém - não há filtragem para determinar se um pacote é estável, arriscado etc. A existência de dois sites foi solicitada por alguns desenvolvedores de pacotes que queriam distinguir versões de desenvolvimento de seus pacotes das versões mais antigas ("stable ") versões.

   Em resumo, não há nada inerentemente mais "estável" no conteúdo de "MELPA estável" . A numeração da versão e o método de alimentação podem ser diferentes; Isso é tudo. E se um mantenedor de pacote específico deseja distinguir versões "estáveis" de "desenvolvimento" e deseja fazer isso enviando-as para os dois sites diferentes, esse é o efeito - para esse pacote .

2. Uma diferença entre MELPA e Marmalade (e GNU ELPA) é que não é necessário que o código contribuído para MELPA seja originado de um repositório git. Em particular, ele pode ser extraído automaticamente da Área Elisp do Wiki do Emacs .

   Isso significa, como alguns já disseram, que qualquer pessoa pode fazer upload de qualquer coisa, e você não tem como saber se o código é realmente do autor reivindicado, etc.? Sim e não. Em geral, sim: qualquer pessoa é livre para fazer o upload do código Elisp no Emacs Wiki. Como o topo da página Elisp-Area diz:

   Essa é a área elmac do EmacsWiki, onde coletamos os arquivos do EmacsLisp. Não é necessário fazer login, não é necessário controle de versão, não é necessário ftp, não é necessária senha. É tão simples quanto o próprio wiki. Isso também significa que qualquer pessoa pode colocar código malicioso nesses arquivos do EmacsLisp. Em caso de dúvida, não os use.

   No entanto, só para você saber, eu sou um administrador do wiki e minhas próprias bibliotecas Lisp na área Elisp do wiki são páginas bloqueadas. Isso significa que apenas um administrador do wiki pode enviá-los. Portanto, nesse caso, você pode ter certeza de que as bibliotecas minhas que você baixa do MELPA ou do Emacs Wiki foram carregadas por mim. Como em tudo na Internet, no entanto, não há garantia garantida, assim como não há garantia no próprio código. Como diz a sinopse da GPL em todas as bibliotecas da GPL:

   Este programa é distribuído na esperança de que seja útil, mas SEM QUALQUER GARANTIA; sem sequer a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM OBJETIVO ESPECÍFICO. Veja a Licença Pública Geral GNU para mais detalhes.

HTH. Feliz hacking.