Por que as bibliotecas são enviadas separadamente, em vez de agrupadas em todos os programas?

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 o nosso programa. Ele não funcionará sem essa biblioteca, mas a biblioteca está estável por um tempo e permanecerá assim no futuro próximo. Não vejo nenhuma razão para NÃO desmembrá-lo.

Que argumentos eu poderia usar para convencê-los?

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

Para resumir a discussão lá:

Separar:

• Um pouco mais fácil de portar para Python 3 (pequeno argumento IMHO)

• Embalagem mais fácil para distribuições

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

• "Dependências de empacotamento e manuseio são problemas difíceis, mas estão resolvidas. Definitivamente, não é uma área em que devemos fazer nossas próprias coisas."

Continue agrupando:

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

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

• não há outro pacote que possa fazer o trabalho de mpmath

• "Quando eu, como usuário, faço o download do sympy, espero que funcione."

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

Mais uma resposta, mas que considero a mais importante (apenas minha opinião pessoal), embora as outras sejam todas boas respostas também.

Empacotar a lib separadamente permite que ela seja atualizada sem a necessidade de atualizar o aplicativo. Digamos que haja um bug na lib, em vez de apenas poder atualizar a lib, você precisaria atualizar o aplicativo inteiro. O que significa que seu aplicativo precisaria de um aumento de versão sem que seu código fosse alterado, apenas por causa da lib.

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

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

• Caso isso seja ú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 a separar) ajudaria a torná-la mais genérica, o que provavelmente melhorará sua qualidade.

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

Aqui estão mais alguns argumentos contra o agrupamento:

• No Linux, é tarefa do mantenedor da distribuição garantir que sua biblioteca funcione bem com suas dependências. De qualquer forma, a maioria dos usuários fará o download da 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.

• No Windows e no Mac OS, os gerenciadores de pacotes Python, como o pip, geralmente são usados ​​de qualquer maneira, já que a instalação manual de bibliotecas é complicada.

• Houve até argumentos sobre a implantação difícil no Google app engine, mas nem todas as estruturas da web são executadas nele. Muitos ainda exigem portabilidade, o espaço em disco para bibliotecas é limitado e, afinal, é 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 tiver a versão errada.

• As pessoas frequentemente odeiam quando o programa se considera mais inteligente do que é. Permita que os usuários cuidem de seu próprio sistema.

A maneira correta de lidar com o desmembramento em um pacote do instalador do Windows seria fazer o teste de pré-instalação da existência da biblioteca e, se não houver, oferecer a instalação do pacote de bibliotecas que você inclui no pacote do instalador do software. Tenho certeza de que a maioria dos aplicativos GTK que possuem portas Windows faz algo nesse sentido - eu sei que o pidgin faz.

Um tamanho não precisa servir para todos.

Para distribuições de código-fonte, se você agrupar, os empacotadores de muitas distribuições (pelo menos nas heranças do Debian e do Fedora) terão que fazer um trabalho adicional para desativar ou remover o pacote, pois as políticas de pacote para essas plataformas proíbem ou pelo menos desencorajam fortemente o pacote. Portanto, agrupando você está criando mais trabalho para o seu downstream com muito pouco benefício. Esse argumento pode ter algum peso?

Distribuições binárias (se você as fornecer) podem ser de qualquer maneira; o agrupamento provavelmente faz sentido para eles, pois eles não são usados ​​pelo downstream.

Mas não há razão para que você não possa tomar a decisão e o pacote opostos para instaladores de Windows e Mac.

Agrupar versus depender é um antigo debate no mundo das embalagens. Este documento fala sobre essas duas escolas de pensamento: http://www.aosabook.org/en/packaging.html