Por que as bibliotecas são enviadas separadamente, em vez de serem incluídas em todos os programas?

Question

Eu sei por que isso é bom em geral: correções de segurança mais rápidas, empacotamento mais fácil, mais recursos. No entanto, estou tentando convencer alguns colegas de trabalho de que não precisamos agrupar uma biblioteca com nosso programa. Não funcionará sem essa biblioteca, mas a biblioteca está estável há algum tempo e continuará sendo assim no futuro previsível. Eu não vejo nenhum motivo para NÃO desmembrá-lo.

Que argumentos eu poderia usar para persuadi-los?

Minha situação específica é esta: estou trabalhando em SymPy , que é uma biblioteca Python de código aberto para matemática simbólica. Uma parte essencial é mpmath , que é uma biblioteca para aritmética de ponto flutuante de várias previsões. O SymPy não funciona sem o mpmath, não há alternativa. Como tal, ele vem junto com o SymPy desde o início (me disseram que geralmente havia pequenas incompatibilidades para corrigir toda vez que uma nova versão é importada). Também deve ser notado que o desenvolvedor do mpmath costumava estar envolvido no desenvolvimento do SymPy. Agora existe um problema no unbundling mpmath, você pode ler tudo aqui .

Para resumir a discussão:

Unbundle:

• Portando um pouco mais fácil para o Python 3 (menor argumento IMHO)

• Embalagem mais fácil para distribuições

• Atualizações de recursos mais rápidos (segurança) para usuários

• "As dependências de empacotamento e manuseio são problemas difíceis, mas são resolvidos. Definitivamente, essa não é uma área em que devemos fazer nossas próprias tarefas".

Manter o agrupamento:

• Instalação. É fácil no Linux, mais difícil no Mac e muito difícil no Windows. Falta de acesso e outros problemas.

• é parte integrante do SymPy, ou seja, o sympy não funciona sem ele (de todo)

• existe não outro pacote, que pode fazer o trabalho de mpmath

• "Quando eu, como usuário, baixei o sympy, espero que funcione."

Essa é a minha situação específica, mas eu aceito uma resposta que forneça uma boa resposta geral também.

    

Answer 1

Ainda outra resposta, mas uma que eu considero ser a mais importante (apenas minha própria opinião pessoal), embora as outras sejam todas boas respostas também.

Embalar a lib separadamente permite que a lib seja atualizada sem a necessidade de atualizar o aplicativo. Digamos que há um bug no lib, em vez de apenas ser capaz de atualizar o lib, você teria que atualizar o aplicativo inteiro. O que significa que seu aplicativo precisaria de uma versão bump sem que seu código tenha sido alterado, apenas por causa da lib.

    

Answer 2

Além das vantagens que você mencionou (segurança, embalagem, recursos), consigo pensar em mais:

• Alguém que acharia a funcionalidade útil para outro programa não precisaria fazer o trabalho de separá-la. Isto é, se ela sabe mesmo se a funcionalidade existe em seu projeto na forma de uma biblioteca em primeiro lugar. Isso depende de quão bem ele foi projetado ... se o seu projeto for modular o suficiente.

• No caso de isso ser útil para outros projetos, isso reduziria o tamanho do uso do disco em geral (por exemplo, apenas uma cópia do código).

• Isso melhoraria a qualidade do seu código, forçando você a fazer alguma refatoração (muito necessária). Como no primeiro ponto acima, isso também depende da qualidade do seu código.

• Aumentar o número de usuários da biblioteca (se for dividida) ajudará a torná-la mais genérica, o que provavelmente melhorará sua qualidade também.

Answer 3

Embora as vantagens sejam óbvias, a facilidade de implantação parece ser o principal argumento para o envio da biblioteca junto com o programa no seu caso.

Veja mais alguns argumentos contra o empacotamento:

• No Linux, é o trabalho do mantenedor da distribuição garantir que sua biblioteca funcione bem com suas dependências. A maioria dos usuários irá, em qualquer caso, baixar a biblioteca usando o gerenciador de pacotes da distribuição. Aqueles que estão usando o tronco geralmente não se importarão de gastar tempo configurando a biblioteca de qualquer maneira.

• No Windows e no Mac OS, os gerenciadores de pacotes do Python, como o pip, são geralmente usados de qualquer maneira, já que instalar as bibliotecas manualmente é complicado.

• Houve até argumentos sobre a implantação difícil no mecanismo do Google app, mas nem todos os frameworks da web são executados nele. Muitos exigem até portabilidade, o espaço em disco para as bibliotecas é limitado e, afinal, é a hospedagem de aplicativos da Web! É improvável que o aplicativo da Web use matemática simbólica.

• Ninguém impede que você exiba mensagens de erro limpas se a dependência não estiver disponível ou se tiver a versão errada.

• As pessoas geralmente odeiam quando o programa se considera mais esperto do que eles. Deixe os usuários cuidarem de seu próprio sistema.

Answer 4

A maneira correta de manipular o unbundled em um pacote do Windows Installer seria ter o teste preinst para a existência da biblioteca e, se não estiver presente, oferecer para instalá-lo a partir do pacote da biblioteca que você incluir no pacote do instalador de software. Tenho certeza que a maioria dos aplicativos GTK que possuem portas do Windows fazem algo ao longo dessas linhas - eu sei que o pidgin funciona.

    

Answer 5

Um tamanho não precisa caber em todos.

Para distribuições de fontes, se você empacotar, empacotadores em muitas distribuições (pelo menos das heranças Debian e Fedora) terão que fazer um trabalho adicional para desabilitar ou remover o empacotamento, pois as políticas de pacotes dessas plataformas proíbem ou pelo menos desencorajam strongmente empacotamento. Portanto, ao agrupar, você está criando mais trabalho para seu downstream com muito pouco benefício. Esse argumento tem algum peso?

Distribuições binárias (se você fornecê-las) podem ir de qualquer maneira; o empacotamento provavelmente faz sentido para aqueles, já que eles não são usados pelo downstream.

Mas não há motivos para que você não possa tomar a decisão oposta e se encaixar nos instaladores de Windows e Mac.

    

Answer 6

Agrupar versus depender é um velho debate no mundo das embalagens. Este documento fala sobre essas duas escolas de pensamento: link