Quando é (não) apropriado para agrupar dependências com um aplicativo?

Question

Resumo

Recentemente, tive uma conversa com o criador de uma estrutura da qual um dos meus aplicativos depende. Durante essa conversa, ele mencionou como uma espécie de que isso tornaria minha vida mais simples se eu acabei de agrupar sua estrutura com meu aplicativo e entregue ao usuário final uma versão que eu sabia que era consistente com o meu código. Intuitivamente, eu sempre tentei evitar fazer isso e, de fato, tomei dores em segmentar meu próprio código para que partes dele pudessem ser redistribuídas sem levar o projeto inteiro (mesmo quando havia uma pequena chance preciosa que alguém jamais reutilizasse qualquer um dos isto). No entanto, depois de refogá -lo por algum tempo, não consegui encontrar um motivo particularmente bom Por quê Eu faço isso. De fato, agora que pensei nisso, estou vendo um caso bastante atraente para agrupar tudo minhas dependências menores. Eu criei uma lista de prós e contras e espero que alguém possa apontar qualquer coisa que esteja perdendo.

Prós

• A consistência de versões significa testes e solução de problemas mais fáceis.
• O aplicativo pode atingir um público mais amplo, pois parece haver menos componentes para instalar.
• Pequenos ajustes para a dependência podem ser mais facilmente feitos a jusante e entregues com o aplicativo, em vez de esperar que eles percolem na base de código a montante.

Contras

• Processo de embalagem mais complexo para incluir dependências.
• O usuário pode acabar com várias cópias de uma dependência de sua máquina.
• De acordo com a resposta de Bortzmeyer, existem possíveis preocupações de segurança em não ser capaz de atualizar componentes individuais.

Notas

Para referência, meu aplicativo está escrito em Python e as dependências que estou referenciando são "luz", com o que quero dizer pequeno e não em uso muito comum. (Portanto, eles não existem em todas as máquinas ou mesmo em todos os repositórios.) E quando digo "pacote com" meu aplicativo, quero dizer distribuir sob minha própria árvore de origem, não instalar com um script que reside dentro do meu pacote, para que haja Não ter chance de versões conflitantes. Também estou desenvolvendo apenas o Linux, para que não haja problemas de instalação do Windows para se preocupar.

Tudo isso dito, estou interessado em ouvir qualquer pensamento sobre a questão mais ampla (independente do idioma) das dependências de embalagem. Existe algo que estou perdendo ou é uma decisão fácil que estou pensando demais?

Adendo 1

Vale ressaltar que eu também sou bastante sensível às necessidades dos pacotes a jusante. Eu gostaria que fosse o mais simples possível para encerrar o aplicativo em um Deb ou RPM específico de distribuição.

Answer 1

Eu sou a favor de dependências agrupadas, E se Não é viável usar um sistema para resolução automática de dependência (ou seja, setUptools) e E se Você pode fazer isso sem apresentar conflitos de versão. Você ainda precisa considerar seu aplicativo e seu público; Desenvolvedores ou entusiastas sérios são mais propensos a querer trabalhar com uma versão específica (mais recente) da dependência. Coisas de agrupamento podem ser irritantes para eles, pois não é o que eles esperam.

Mas, especialmente para usuários finais de um aplicativo, duvido seriamente que a maioria das pessoas goste de ter que procurar dependências. No que diz respeito a ter cópias duplicadas, eu preferiria gastar mais 10 milissegundos baixando alguns kilobytes adicionais ou gastar qualquer fração de um centavo no espaço extra de disco, do que gastar mais de 10 minutos pesquisando em sites (que podem estar baixos ), baixando, instalando (que pode falhar se as versões forem incompatíveis), etc.

Não me importo com quantas cópias de uma biblioteca eu tenho no meu disco, desde que elas não entrem no caminho um do outro. O espaço em disco é muito, muito barato.

Answer 2

Você não pode simplesmente confiar em uma certa versão dessas dependências? Por exemplo, em python com SetupTools Você pode especificar qual versão exata ele precisa ou até fornecer algumas condições como <=> etc. Isso, obviamente, se aplica apenas ao Python e ao gerenciador de pacotes Specifc, mas eu pessoalmente sempre tentaria primeiro não agrupar tudo. Com o envio como um ovo python, você também terá todas as dependências instaladas automaticamente.

É claro que você também pode usar uma estratégia de mão dupla para fornecer ao seu próprio pacote apenas links para as dependências e, no entanto, fornecer uma configuração completa em algum instalador como a moda. Mas mesmo assim (no caso Python), sugiro simplesmente agrupar os ovos com ele.

Para alguma introdução em ovos, consulte Este post meu.

É claro que isso é muito específico do Python, mas presumo que outro idioma possa ter ferramentas de embalagem semelhantes.

Answer 3

Se você está produzindo software para um usuário final, o objetivo é deixar o cliente usar seu software. Qualquer coisa que esteja no caminho é contraproducente. Se eles precisam baixar as dependências, existe a possibilidade de decidir evitar seu software. Você não pode controlar se as bibliotecas serão compatíveis com versões anteriores e não deseja que seu software pare de funcionar porque o usuário atualizou o sistema deles. Da mesma forma, você não deseja que um cliente instale uma versão antiga do seu software com bibliotecas antigas e tenha o restante da quebra do sistema.

Isso significa que o agrupamento geralmente é o caminho a percorrer. Se você puder garantir que seu software instale sem problemas sem dependências de agrupamento, e isso é menos trabalho, essa pode ser uma opção melhor. É sobre o que satisfaz seus clientes.

Answer 4

Para o Linux, nem pense em agrupar. Você não é mais inteligente que o gerenciador de pacotes ou os pacotes, e cada distribuição se aproxima do seu jeito - eles não ficarão felizes se você tentar seguir seu caminho. Na melhor das hipóteses, eles não se incomodam em embalar seu aplicativo, o que não é ótimo.

Lembre -se de que, no Linux, as dependências são automaticamente puxadas para você. Não é uma questão de fazer o usuário obtê -los. Já está feito para você.

Para o Windows, fique à vontade para agrupar, você está sozinho lá.

Answer 5

Um ponto importante parece ter sido esquecido nos contras das bibliotecas/estruturas/etc. com o aplicativo: atualizações de segurança.

A maioria das estruturas da Web está cheia de orifícios de segurança e requer patches frequentes. De qualquer forma, qualquer biblioteca pode ser atualizada um dia ou a outra para um bug de segurança.

Se você não agrupar, os sysadmins apenas atualizam uma cópia da biblioteca e reiniciarão aplicativos.

Se você agrupar, os sysadmins provavelmente nem sequer conhecer Eles têm que atualizar algo.

Portanto, o problema com o agrupamento não é o espaço em disco, é o risco de deixar cópias antigas e perigosas.

Answer 6

Apenas minha experiência, leve -a com um grão de sal.

Minha preferência por algumas bibliotecas de código aberto que eu autor é por independência de LIBs adicionais o máximo possível. Razão sendo, não apenas estou no gancho para distribuição de bibliotecas adicionais, juntamente com as minhas, também sou obrigado a atualizar meu aplicativo para compatibilidade, pois essas outras bibliotecas também são atualizadas.

Nas bibliotecas que usei de outras pessoas que carregam dependências de bibliotecas "comuns", invariavelmente acabo exigindo várias versões da biblioteca comum no meu sistema. A velocidade de atualização relativa das bibliotecas de nicho que estou usando simplesmente não é tão rápida, enquanto as bibliotecas comuns são atualizadas com muito mais frequência. Versão do inferno.

Mas isso está falando genericamente. Se posso ajudar meu projeto e usuários agora incorporando uma dependência, estou sempre olhando para os efeitos a jusante e posteriormente dessa decisão. Se eu puder gerenciá -lo, posso incluir com confiança a dependência.

Como sempre, sua milhagem pode variar.

Answer 7

Eu sempre incluo todas as dependências para meus aplicativos da Web. Isso não apenas simplifica a instalação, o aplicativo permanece estável e funciona da maneira que você espera, mesmo quando outros componentes do sistema são atualizados.

Answer 8

Cuidado, reproduzindo o clássico Windows DLL HELL. Por todos os meios, minimize o número de dependências: Idealmente, dependa apenas do seu idioma e da estrutura, nada mais, se puder.

Afinal, preservar o espaço do disco rígido dificilmente é mais o objetivo, portanto os usuários não precisam se importar em ter várias cópias. Além disso, a menos que você tenha um número minúsculo de usuários, certifique -se de levar o ônus da embalagem em vez de exigir que eles obtenham todas as dependências!