Quais são os casos de uso de gerenciadores de pacotes alternativos em relação ao `package.el`?


14

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?


2
Veja também: quelpa . A resposta curta é: Claro, ainda existem pacotes que não estão no ELPA / MELPA / Marmalade. Se você achar que precisa de um, ainda poderá obtê-lo sem hacks horríveis el-gete similares.
precisa saber é o seguinte

Respostas:


8

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.


"se eles não fizessem, ainda se incomodariam em mantê-los." O objetivo pode ser apenas o ego do desenvolvedor.
T. Verron

Seria um ego poderoso, porém, que poderia facilmente atrair como uma grande comunidade como el-obter ainda tem, e QUELPA rapidamente ganhou :)
lunaryorn

Eu estava comentando em geral, é claro. ;)Para as especificidades dos pacotes em mãos, sua resposta, além da afirmação de bom senso, é um ponto forte ao exibir o objetivo de el-get e quelpa.
T. Verron

@ T.Verron Sim, ponto de vista. Eu removi essa afirmação, foi uma coisa estúpida de se dizer. Desculpe.
lunaryorn

@ lunaryorn com el-get, however, does not expose its own packages to ELPA, meaning that **its packages** are entirely invisible to ELPA and ELPA você quer dizer as coisas instaladas pela el-get, certo?
toogley 9/08/16

6

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;)

4

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.


Lamento que você tenha tido problemas com Cask, mas não acho que seus problemas pessoais e sua aparente frustração com Cask tenham qualquer relevância para essa questão. Especificamente, o Cask é frontend do ELPA com um escopo muito restrito (principalmente desenvolvimento de pacotes). Embora você possa usá-lo também para gerenciamento de pacotes, é conceitualmente ortogonal a el-get.
lunaryorn

Em outras palavras, Cask não substitui el-get, nem pretende fazê-lo. É totalmente independente. O ELPA substitui o el-get. A melhor opção para instalações baseadas em Git não é mais el-get, é QUELPA, e como eu disse na minha resposta, esse é um motivo válido para usar o QUELPA.
lunaryorn

1
Eu concordo com o escopo restrito do Cask, não me interpretem mal. Apesar dos meus "problemas" com o Cask, ainda o uso em algumas máquinas Linux. Também não tenho pacotes "git-only", alguns deles estão em sistemas de controle de versão mercurial ou outros. Eu também uso pacotes de outras pessoas que provavelmente nunca estarão no MELPA ou em um repositório git. Meu único argumento é que el-get ainda está ok quando o MELPA não contém todos os pacotes necessários para alguém. Enquanto eu estou ciente da QUELPA, el-get é bom o suficiente para mim.
rimero

Veja, e o que quero dizer é que el-get especificamente não está mais certo hoje em dia, porque ignora o gerenciamento de dependências interno do ELPA e Emacs, arriscando a quebra e instalações duplicadas de pacotes. O QUELPA fornece os mesmos recursos que o el-get, mas não possui essa falha. Hoje é melhor ainda.
lunaryorn

@rimero Eu tive exatamente a mesma experiência. Além disso, tentei o Quelpa há alguns dias e tive que abandoná-lo, pelo menos por enquanto. O El-get ainda parece ser mais flexível, poderoso e, em geral, mais rápido, pelo menos para o meu caso de uso. Eu acredito que eles adotam duas perspectivas bem diferentes, então também pode depender do tipo de usuário do Emacs. Seria aconselhável tentar os dois antes de se comprometer com um ou outro.
GSL

1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.