fundo

Eu uso o emacs diariamente, mas principalmente para fazer as coisas. Eu realmente não gosto de personalizá-lo mais do que adicionar pacotes e não gosto de solucionar problemas. Eu quero que o emacs desapareça em segundo plano da maneira que um bom sistema operacional faz e continue com as coisas. Há um tempo, descobri que el-getme permitia instalar os pacotes que eu precisava e que estavam indisponíveis package.ele também me dava mais controle, como selecionar a maintramificação do modo Org em vez da borda sangrenta, o que pode causar problemas temporários. Agora não tenho certeza se devo usar el-getou não.

Questão

el-getparecia ser uma ótima solução para os vários repositórios e emacs hacks por aí. Oferecia recursos que simplesmente não eram possíveis package.el. Agora que package.elnas versões mais recentes do emacs ( >=24.4) suporta vários repositórios, para que servem os casos de uso el-gete alternativas semelhantes ao gerenciador de pacotes interno do emacs?

Existem coisas que ainda são impossíveis com o ELPA e há sempre que são impossíveis com o ELPA, porque elas não se encaixam no conceito de ELPA: você nunca poderá instalar um commit específico por seu hash a partir de um bifurcação. repositório. Da mesma forma, você nunca poderá aplicar patches locais personalizados a um pacote antes de instalá-lo. Esses recursos estão simplesmente fora do escopo do ELPA e, se você precisar deles, precisará usar um gerenciador de pacotes alternativo.

Penso, porém, que el-get é uma espécie de solução legada hoje em dia. Dado que o ELPA se tornou o gerenciador de pacotes padrão de fato do Emacs, os gerentes de pacotes alternativos devem se integrar perfeitamente ao ELPA. A el-get, no entanto, não expõe seus próprios pacotes ao ELPA, o que significa que seus pacotes são totalmente invisíveis para os pacotes ELPA e ELPA nunca podem depender dos pacotes el-get, com implicações óbvias para o gerenciamento de dependências.

Se você precisar de recursos além do ELPA, deve procurar o QUELPA hoje em vez do el-get.

Eu escrevi um novo gerenciador de pacotes para o Emacs straight.el, que tenta melhorar todas as soluções de gerenciamento de pacotes existentes. Há uma seção extensa na straight.eldocumentação sobre comparações com outros gerenciadores de pacotes , mas aqui está um breve resumo:

• package.elbaixa tarballs opacos de servidores centrais, sem opção para selecionar uma versão específica de um pacote e não permite fazer alterações locais em seus pacotes; contribuir com mudanças a montante é impossível. straight.elclona os repositórios Git de maneira descentralizada (mas usa automaticamente receitas do MELPA , GNU ELPA e EmacsMirror , se desejar) e permite fazer alterações locais arbitrárias neles, confirmar essas alterações e contribuir com a produção. Isso pode ser feito manualmente ou você pode usar as operações internas de gerenciamento de repositório em massa. As alterações nos seus pacotes são detectadas automaticamente e não são necessárias recriações manuais. Além disso,straight.el suporta reprodutibilidade completa para sua configuração do Emacs, pois permite escrever um arquivo de bloqueio de revisão que inclui os hashes Git de todos os seus pacotes.
• Quelpa e Cask são baseados package.ele herdam muitas das mesmas desvantagens. Por exemplo, Cask não tem nenhum conceito de instalação de uma versão específica de um pacote. Quelpa faz, mas requer que você codifique o hash Git no seu arquivo init. straight.elevita package.elcompletamente, substituindo toda a sua funcionalidade principal por um design unificado, adaptado a muitos outros casos de uso.
• O el-get tem a vantagem de poder instalar pacotes de qualquer lugar (todos os sistemas conhecidos de controle de versão, HTTP arbitrário, gerenciadores de pacotes do sistema, EmacsWiki, até mesmo go get!?). No entanto, ao oferecer suporte a muitas fontes, a el-get não pode fornecer o tipo de operações avançadas de gerenciamento de pacotes (como reprodutibilidade através de arquivos de bloqueio de revisão e operações de gerenciamento de repositório interativo) que straight.elfornece. straight.elsuporta apenas o Git, já que a maioria dos pacotes está disponível no Git e os que não existem podem ser obtidos através do EmacsMirror (eu te desafio a encontrar um que não pode ser!). Observe que, straight.elno entanto, fornece uma API extensível para back-end adicionais de controle de versão (por exemplo, para Mercurial) a serem adicionados no futuro, se desejado.
• Borg tem uma filosofia muito semelhante straight.ele oferece muitas das mesmas vantagens. No entanto, ele não foi projetado para ser um gerente pacote completo, e é projetado para ser usado em preocupação com outras ferramentas, como epkg, auto-compilee magit. Pelo contrário, straight.elé independente e fornece tudo o que você precisa por si só, exigindo pouca ou nenhuma configuração adicional. Além disso, o Borg usa sub-módulos Git, cuja interface possui algumas arestas, enquanto straight.elusa repositórios Git gerenciados independentemente, fornecendo flexibilidade e energia adicionais.
• Há também a abordagem manual, mas eu não recomendo isso. Após os primeiros meses, você teria reinventado o Borg. Depois dos próximos meses, você teria se reinventado straight.el. Você aprenderá muito sobre gerenciamento de pacotes;)

Embora existam prós e contras, acho que o el-get ainda é relevante, apesar das fortes opiniões do @lunaryon (rejeite também).

Eu usei raw package.el com use-package por um tempo (2 a 3 anos), depois mudei para el-get e depois Cask . Voltei para el-get alguns dias atrás. Antes do package.el , como muitos outros, eu estava lidando manualmente com complementos.

Por que eu voltei para el-get ? Eu encontrei alguma estranheza do Cask sobre algo não ser um repositório git (um pacote meu do Github que não está no MELPA), enquanto esse pacote está realmente usando o git ... Eu não me incomodei em investigar ou criar um ticket, apenas peguei meu el-get config e eu estava pronto para ir em pouco tempo.

Poucas coisas que eu gosto no el-get :

• Ele suporta vários buscadores, não apenas o git.
• Contém receitas predefinidas suficientes
• Mais rápido que Cask na inicialização.
• e sim @lunaryorn, o Wiki não é um lugar para distribuir código, ainda não quero criar um repositório do Github se não houver clone no emacsmirror (Github).
• Independente, com o Cask você precisa de uma instalação externa. Eu uso um único arquivo init (não uma configuração modular) com o modo allout para navegar pelas seções.
• O el-get é bastante simples da perspectiva do usuário.

Nota: Estou executando o Emacs Git HEAD no OSX e Linux.

Você pode querer dar uma olhada paradox. Não é outro gerenciador de pacotes, mas um front end mais limpo package.el. Por exemplo, quando você atualiza pacotes, ele pergunta se você deseja instalá-los e excluir os antigos em uma etapa.

Se você usá-lo, você provavelmente vai querer conjunto paradox-execute-asynchronouslypara tno seu arquivo de inicialização.