O que você espera de um gerenciador de pacotes para o Emacs? [fechadas]

https://stackoverflow.com/questions/454259

19-08-2019
|

Pergunta

Apesar de existirem vários milhares de bibliotecas Emacs Lisp, GNU Emacs, até a versão 24.1 não tem um gerenciador de pacotes (interno).

Eu acho que a maioria dos usuários concordaria que atualmente é bastante inconveniente para encontrar, instalar e, especialmente, manter up-to-date bibliotecas Emacs Lisp.

Páginas que vida ter um pouco mais fácil

Para versões de Emacs com mais de 24,1:

Emacs Lista Lisp - Problema: See dead People (links).
Emacswiki - Problema:. Pode conter vestígios de nozes (códigos maliciosos)
Emacsmirror - O repositório de pacotes que eu estou trabalhando. Problema:. Nenhum gerente pacote suporta ainda nativamente

Alguns gestores de pacotes

Não é que ninguém tentou ainda. (Alguns deles não existia quando esta pergunta foi feita.)

auto-instalar
borg.el -. Pacotes Assimilate Emacs usando submódulos Git
el-get.el - suporta várias fontes.
elinstall.el
epackage aka DELPS - Debian conceitos de embalagem aplicada a pacotes de Emacs Lisp.
epkg.el -. Esta é agora apenas uma ferramenta para navegar na Emacsmirror
install.el
instalar-elisp.el
jem-pkg.el
package.el - ELPA. Parece que será incluído no Emacs 24.

Atualização - package.el está incluída no GNU Emacs, a partir da versão 24.1

pases.el
Pelm - Comando instalador de linha; usando php.
plugin.el
straight.el -. Recentes e experimental, não chegou a versão 1.0 ainda
uso da package.el
XEmacs gerenciador de pacotes

pacote foi incluído no porta-malas Emacs. epkg ainda não está pronto e também não está disponível. Pelo menos instalar-elisp, plugin e-package uso não parecem estar ativamente mais mantida.

Eu criei um git repositório contendo todos esses gerenciadores de pacotes como submódulos.

Alguns utilitários que podem ser úteis

Gerenciadores de pacotes poderia usar esses utilitários e / ou eles poderiam ser usados ??para manter um espelho de pacotes.

data-calc.el - Date cálculo e rotinas de análise.
ell.el - procurar as Emacs Lista Lisp.
elm.el , elx.el , xpkg.el - Usado para manter a Emacsmirror .
genauto.el - ajuda a gerar autoloads para o seu pacotes elisp.
inversion.el -. Exigir versões específicas de pacotes
loadhist.el, lib-requires.el, elisp-depend.el - Comandos à lista Emacs Lisp dependências da biblioteca.
projeto-root.el - Definir um projeto raiz e tomar medidas com base nela.
strptime.el -. Implementação parcial da data POSIX e análise de tempo
wikirel.el -. Páginas relevantes visita no Emacs Wiki

As discussões sobre o assunto em mãos

A pergunta (finalmente)

Assim -. Eu gostaria de saber de você o que você considera importante / sem importância / suplementar etc. em um gerenciador de pacotes para o Emacs

Algumas idéias

Muitos pacotes (o Emacsmirror prevê que a maior coleção disponível de pacotes, mas não há nenhum apoio explícito em qualquer gerenciador de pacotes ainda).
Apenas os pacotes que foram testados.
Suporte para mais de um repositório de pacotes (que as pessoas possam escolher entre muitos / pacotes testados).
Dependência calculados com base nas características exigidas somente.
Dependências tomar versões particulares em conta.
Use apenas versões que foram lançadas a montante.
Use as versões de sistemas de controle de versão, se disponível.
Os pacotes são categorizados.
Os pacotes podem ser desinstalado e atualizado não apenas instalado.
Suporte a criação de garfo de versão upstream de pacotes.
Suporte publicação desses garfos.
Suporte a escolha de um garfo.
Depois de pacotes de instalação são ativados.
Gerar arquivos de carregar automaticamente.
Integração com Emacswiki (veja wikirel.el).
Os usuários podem marcar, comentar pacotes etc. e compartilhar essa informação.
Apenas FSF-atribuído / GPL software / FOSS ou não se preocupam com licença.
Gerenciador de Pacotes deve ser integrado ser distribuído com o Emacs.
Suporte para entrar em contato facilmente autor.
Muitos dos metadados.
Sugerir alternativas antes de instalar um pacote particular.

Estou esperando para estes tipos de respostas

Ponteiros para mais implementações, discussões etc.
longas descrições de um conjunto de características que compõem o seu gerenciador de pacotes ideal.
Descrição de uma desejada featu especial / indesejadaré. Sinta-se livre para a reflexão sobre as minhas ideias de cima.
Surprise mim.

Solução

publicar automático de controle de versão

Eu adoraria ver um única pacote Emacs gerente standard, central, e. Agora, eu colocaria meu dinheiro em ELPA , mas ainda há um longo caminho a percorrer.

A maior coisa que ajudaria um gerenciador de pacotes Emacs seria torná-lo super trivial para publicar pacotes. Na minha opinião, eu gostaria de ver isso acontecer em combinação com um sistema de controle de versão como git em uma plataforma hospedada Central como GitHub -. algo que tornaria mais fácil para os autores a publicar seus pacotes e tornaria mais fácil para os outros a contribuir para trás

Semelhante à forma como GitHub (usado para) torná-lo fácil de publicar RubyGems, eu gostaria de ver algo semelhante em um gerenciador de pacotes Emacs. Por exemplo, tag seu repositório com "vX.Y.Z" e ter sua bondade elisp automaticamente disponível para todos.

A vantagem de usar um backend popular como o GitHub é que você deseja obter imediatamente um monte de exposição, que deve ajudar a impulsionar o seu sucesso.

Outras dicas

Eu ainda estou aprendendo Emacs, então eu não tive a oportunidade de olhar para gestores de pacotes, mas um grande recurso seria para informar ao usuário que o pacote está disponível se tentar usá-lo, mas não é em seu sistema. Por exemplo, eu queria editar um arquivo PHP em um servidor uma vez, e eu tentei

M-x php-mode

e Emacs era tudo como

M-x php-mode [no match]

quando deveria ter sido como

php-mode available from ftp.gnu.org. install? (y/n)

e, em seguida, que teria instalado e carregado de modo php para mim. Isso teria feito o meu dia ali.

O que eu espero mais é que tudo útil é sobre ele, e funciona bem. Isso requer que você (ou uma equipe de mantenedores) para perseguir agressivamente embalar tudo para ele, e fazendo tudo o que envolve - e-mail todos os autores de um pacote útil, e assim por diante.

Por exemplo, a razão Debian (e seus derivados: Ubuntu etc.) é tão bom é que você pode facilmente usar o seu sistema sem ter que instalar algo fora dos repositórios, e que tudo nele é exaustivamente testado. As características reais do gerenciador de pacotes são importantes, mas secundário para os próprios pacotes gerenciados.

Fácil configuração de sincronização : Eu, como muitas pessoas, usar Emacs em muitos computadores e servidores diferentes, alguns deles a minha própria e outras não. Seria surpreendente se o gerenciador de pacotes tinham algum tipo de arquivo que eu poderia transferir de um computador para outro; Em seguida, no último computador, o gerenciador de pacotes traria minha Emacs para o estado I like it in - todos os pacotes instalados e configurações definidas. Combinado com a capacidade de ser capaz de instalar facilmente um ou outro local de largura (se tem permissões de root) ou como um único usuário, eu poderia sincronizar todos os Emacsen em todos os lugares.

Estou quase positivo que a melhor solução envolve a apresentação de mais pacotes para ELPA e adicionando suporte multi-fonte para package.el. Os mantenedores do Emacs disseram que considerariam incluindo package.el na versão 24, enquanto ele apontava para um repositório FSF por padrão.

É claro, a apresentação também precisa ser um processo automatizado também; o actual método de envio do mantenedor ELPA só funciona em pequena escala.

Não importa como isso é feito, a coisa mais importante na minha opinião é que ele deve ser trivial para enviar pacotes para o repositório. Ao mesmo tempo, não queremos que os pacotes para ser imediatamente disponíveis, para proteger contra códigos maliciosos (e devido a problemas de licenciamento). A menos que haja um sistema de "confiança" no lugar, baseado em assinaturas de criptografia.

Também útil:

"metapacotes", para instalar vários pacotes ao mesmo tempo.
Da mesma forma, devemos ser capazes de instalar um conjunto de arquivos elisp, para manutenção
"quebrado" pacotes não devem ser autorizados a interromper o arranque Emacs. Isso é fácil e eu tê-lo implementado em minhas próprias .emacs
Capacidade de instalar outros de scripts de arquivos. Este é muitas vezes esquecido, mas muito útil. Você seria capaz de, por exemplo, imagens de navios, por ícones, barras de ferramentas, etc.
de versão: pacote X requer o pacote Y> 1,0
Teste:. Executar verificações básicas de sanidade, testando para conflitos (keybindings, redefinições de funções, funções que devem estar presentes, mas não são, etc)
bug tracking : Não posso salientar a importância deste suficiente. Ter um lugar centralizado para erros de pacotes relatório (e ser capaz de controlá-los) é extremamente importante para garantir a qualidade dos pacotes.

Algum tipo de arquivo comprimido parece ser melhor fazer alguma das situações acima.

Até agora, a ELPA muito melhor parece ser o caminho a percorrer.

Uma vez eu passei algum tempo a escrever um pequeno gerenciador de pacotes para o Emacs.

http://gmarceau.qc.ca/plugin.el

Eu escrevi:

Plugin é a minha tentativa de criar uma Gerenciador de Pacotes para o Emacs. Plugar vai transfere automaticamente Emacs extensões, descompacta-los em um diretório, acrescenta que o diretório para o load-path, gera auto-load anotações, e modificar suas dot-emacs Arquivo. As anotações auto-carga são uma característica do Emacs pouco conhecido. Uma vez eles são gerados, extensões do Emacs carregar rapidamente e de forma incremental, que é realmente bom se você tem o maior número extensões instaladas como eu.

Você vai precisar de dois arquivos de biblioteca para obtê-lo a correr, loop-constructs.el e record.el

Eu acho que os hackers para o iPhone ficou bastante perto do que eu quero, assim como do Ubuntu "apt".

Eu gosto de ser capaz de:

add
remove (pacote somente)
configurações do usuário remove
documentação vista
atualizar (depois de ler o log de alterações)
adicionar novo arquivo (aka adicionar repositório)
ver dependências
ver a versão
procurar nome, palavra-chave
Navegar por (data acrescentou, data de modificação, nome)
Salve todos os pacotes e configurações instalados
Conjunto de carga de pacotes e configurações

Eu gostaria de um conjunto principal de coisas que todos funcionam muito bem e são a maneira recomendada de fazer o que quer. Em seguida, um conjunto global onde tudo trabalho entra. Em seguida, a capacidade de alguém para hospedar seu próprio arquivo.

Seria bom se tudo isso foi amarrado em git / svn / whatever para que você possa instalar versões antigas. Faça seus próprios patches pela bifurcação off etc etc etc ....

Além do mencionado acima, eu esperava algo como debian, e outros repositórios - conjunto de estábulo, experemental, pacotes não-testados. Capacidade de adicionar meus próprios repositórios - eu uso muito os pacotes diretamente do VCS, assim que poderia ser útil para criar meus próprios pacotes

Eu acho que o gerenciador de pacotes deve ter um monte de inspiração Rubygems . Eu também acho que ele deve ter um site como Gemcutter .

Um repositório central também poderia ser agradável (como Emacsmirror ). Este, porém, pode não ser necessário se um site como Gemcutter existe que recolhe todos os pacotes.

Eu acho que essas coisas são importantes para que isso funcione.

Localização central de algum tipo que recolhe todos os pacotes
Fácil de adicionar pacotes
Fácil de manter pacotes
Fácil de contribuir para outros pacotes
Fácil de instalar, desinstalar pacotes e atualização
Possibilidade de adicionar dependências de pacotes
Estrutura comum para todos os pacotes

Assim, um gerenciador de pacotes como Rubygems com um site como Gemcutter e um repositório central como Emacsmirror (de preferência no Github porque ele é social, codificação) faria Emacs realmente bom.

Apesar de tudo, acho que muita inspiração deve ser tomada a partir Rails e como Rails alças Gems.

Eu não sei como fresco a esta pergunta é ...
mas o modelo que eu gostaria de ver é CPAN. Eu também não sei Rubygems mas soa semelhante ao CPAN.

CPAN é um perl arquivar + sistema de gerenciamento de biblioteca. Quando eu preciso escrever um programa perl que requer ... FTP ou SOAP ou JSON ou XML ou ZIP ou ... etc, eu posso correr o gerenciador de pacotes CPAN, selecione o pacote requisito para download, visualizar e verificar as dependências, em seguida, instalar tudo. CPAN é espelhado .. "em todos os lugares".

CPAN funciona maravilhosamente para os meus propósitos, e algo semelhante para emacs seria bom ter. Ele também suporta a construção de código C / C ++ na demanda.

Isso é o que eu gostaria de ver no emacs.

Alguns mais comentários sobre requisitos.

Fazer download explícito de pacotes. instalar nenhum auto. Nenhum download invisível. Quero pedir novas bibliotecas ou nova função.
Eu deveria ser capaz de listar o nome / versão / timestamp de pacotes instalados.
Se o meu amigo me dá a sua lista, eu deveria ser capaz de diff estado seus emacs contra o meu.
check-for-atualizações função. Que actualizações estão disponíveis? O que eles corrigir?
verificação nas dependências, verificação e download. Se eu instalar-mode csharp e requer v5.0.28 de-mode cc, em seguida, ele deve confirmar comigo, que eu também deve baixar cc-mode.
deve haver algum tipo de comunidade classificação destes pacotes, como classificação torrentes em isohunt. Eu quero ver se um pacote tem 3 upvotes ou 3000.
comportamento "transacional". Se uma instalação faz boom, deve relaxar a um estado de última em boas condições.
failsafes. Se eu colocar mods personalizadas em linum.el, deve recusar-se a instalar uma nova versão sobre as minhas alterações, a menos que eu permitir que ele explicitamente. Ele deve me avisar antes mesmo de começar. Faça isso com somas de verificação / md5 de sobre a instalação existente.
tem a opção de executar alguns pacotes de arquivos compactados, como arquivos zip. Então, eu nunca tenho qualquer dúvida de que eu não ter atualizado qualquer um dos elisp embbedded.
capacidade de usar anfitriões espelhados para distribuição pacote.
toda essa função deve ser acessível através de M-x biblioteca de manageemnt ou algo assim.

Finalmente, seria bom ter uma maneira de segregar ou organizar bibliotecas de funções. namespaces hierárquicos. namespace plana Emacs' é muito datada. Esta é uma espécie de independente, mas complementar à actividade central de gerenciamento de pacotes. Eu não sou um guru lisp então eu não sei o quão difícil isso seria; talvez já existe uma maneira de fazê-lo.

Gerenciadores de pacotes não oferecem nada de valor que eu w.r.t. pacotes único arquivo elisp com dependências simples: adicionar e excluir de site-lisp nunca causou problemas. É pacotes que dependem de programas externos (por exemplo, ispell), pacotes multi-arquivo (por exemplo, auctex, org-mode) que pode ser complicado. Não consigo pensar em qualquer pacote elisp de arquivo único com dependências não-triviais, de improviso.

Para estes, menos do que um gerenciador de pacotes, eu gostaria elisp-packages Emacs para conjuntos de testes aquisição que podem ser executados em massa, e que fornecem informações úteis em caso de falhas de dependência.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow