Pourquoi les bibliothèques sont-elles expédiées séparément au lieu d'être fournies avec chaque programme?

Je sais pourquoi c'est bon en général: des correctifs de sécurité plus rapides, un packaging plus facile, plus de fonctionnalités. Cependant, j'essaie de convaincre certains collègues que nous n'avons pas besoin de regrouper une bibliothèque avec notre programme. Cela ne fonctionnera pas sans cette bibliothèque, mais la bibliothèque est stable depuis un certain temps maintenant et le restera dans un avenir prévisible. Je ne vois aucune raison de NE PAS le dégrouper.

Quels arguments pourrais-je utiliser pour les convaincre?

Ma situation spécifique est la suivante: je travaille sur SymPy , qui est une bibliothèque Python open source pour les mathématiques symboliques. Une partie centrale de celui-ci est mpmath , qui est une bibliothèque pour l'arithmétique à virgule flottante multi-prévisions. SymPy ne fonctionne pas sans mpmath, il n'y a pas d'alternative. En tant que tel, il est fourni avec SymPy depuis le début (on m'a dit qu'il y avait généralement de petites incompatibilités à corriger à chaque fois qu'une nouvelle version est importée). Il convient également de noter que le développeur de mpmath était auparavant impliqué dans le développement de SymPy. Il y a maintenant un problème sur le dégroupage de mpmath, vous pouvez tout lire ici .

Pour résumer la discussion ici:

Dissocier:

• Portage un peu plus facile vers Python 3 (argument mineur à mon humble avis)

• Emballage plus facile pour les distributions

• Mises à jour des fonctionnalités (de sécurité) plus rapides pour les utilisateurs

• "Les dépendances d'emballage et de manipulation sont des problèmes difficiles, mais elles sont résolues. Ce n'est certainement pas un domaine dans lequel nous devrions faire notre propre travail."

Continuez à regrouper:

• Installation. C'est facile sur Linux, plus difficile sur Mac et très difficile sur Windows. Manque d'accès su et autres problèmes.

• il fait partie intégrante de SymPy, c'est-à-dire que sympy ne fonctionne pas sans lui (du tout)

• il n'y a pas d' autre paquet qui puisse faire le travail de mpmath

• "Quand je, en tant qu'utilisateur, télécharge sympy, je m'attends à ce que ça marche."

C'est ma situation particulière, mais j'accepterais une réponse qui fournit également une bonne réponse générale.

Encore une autre réponse, mais que je considère comme la plus importante (juste mon opinion personnelle), bien que les autres soient également de bonnes réponses.

Empaqueter la lib séparément permet de mettre à jour la lib sans avoir besoin de mettre à jour l'application. Supposons qu'il y ait un bogue dans la bibliothèque, au lieu de pouvoir simplement mettre à jour la bibliothèque, vous devrez mettre à jour l'application entière. Ce qui signifie que votre application aurait besoin d'un bump de version sans que son code ait même changé, juste à cause de la lib.

En plus des avantages que vous avez mentionnés (sécurité, packaging, fonctionnalités), je pense à plus:

• Quelqu'un qui trouverait la fonctionnalité utile pour un autre programme n'aurait pas besoin de faire le travail de séparation. C'est-à-dire si elle sait même si la fonctionnalité existe dans votre projet sous la forme d'une bibliothèque en premier lieu. Cela dépend de la qualité de sa conception ... si votre projet est suffisamment modulaire.

• Dans le cas où cela serait utile pour d'autres projets, cela réduirait la taille de l'utilisation du disque en général (par exemple une seule copie du code).

• Cela améliorerait la qualité de votre code, vous obligeant à effectuer une refactorisation (bien nécessaire). Comme au premier point ci-dessus, cela dépend aussi de la qualité de votre code.

• L'augmentation du nombre d'utilisateurs de la bibliothèque (si elle est scindée) aiderait à la rendre plus générique, ce qui améliorera probablement sa qualité également.

Bien que les avantages soient évidents, la facilité de déploiement semble être l'argument principal pour expédier la bibliothèque avec le programme dans votre cas.

Voici quelques arguments supplémentaires contre le regroupement:

• Sous Linux, c'est le travail du responsable de la distribution de s'assurer que votre bibliothèque fonctionne bien avec ses dépendances. La plupart des utilisateurs téléchargeront en tout cas la bibliothèque en utilisant le gestionnaire de paquets de la distribution. De toute façon, ceux qui utilisent trunk n'auront pas peur de passer du temps à configurer la bibliothèque.

• Sous Windows et Mac OS, les gestionnaires de packages Python comme pip sont généralement utilisés de toute façon, car l'installation manuelle des bibliothèques est fastidieuse.

• Il y a même eu des arguments concernant le déploiement dur sur le moteur d'application Google, mais tous les cadres Web ne fonctionnent pas dessus. Beaucoup nécessitent même un portage, l'espace disque pour les bibliothèques est limité, et c'est l'hébergement d'applications Web après tout! Il est peu probable que l'application Web utilise des mathématiques symboliques.

• Personne ne vous empêche d'afficher des messages d'erreur propres si la dépendance n'est pas disponible ou a la mauvaise version.

• Les gens le détestent souvent lorsque le programme se considère plus intelligent qu'eux. Laissez les utilisateurs prendre soin de leur propre système.

La bonne façon de gérer le dégroupage dans un package d'installation Windows serait d'avoir le test de préinstallation de l'existence de la bibliothèque, et s'il n'est pas présent, de proposer de l'installer à partir du package de bibliothèque que vous incluez dans le package d'installation du logiciel. Je suis presque sûr que la plupart des applications GTK qui ont des ports Windows font quelque chose dans ce sens - je sais que pidgin le fait.

Une taille unique ne doit pas nécessairement convenir à tous.

Pour les distributions sources, si vous regroupez, les packagers de nombreuses distributions (au moins des héritages Debian et Fedora) devront faire un travail supplémentaire pour désactiver ou supprimer le regroupement, car les politiques de package pour ces plateformes interdisent ou du moins découragent fortement le regroupement. Par conséquent, en regroupant, vous créez plus de travail pour votre aval avec très peu d'avantages. Cet argument pourrait-il avoir un certain poids?

Les distributions binaires (si vous les fournissez) pourraient aller dans les deux sens; le regroupement a probablement du sens pour ceux-ci, car ils ne sont pas utilisés par l'aval.

Mais il n'y a aucune raison pour laquelle vous ne pouvez pas prendre la décision et le bundle opposés pour les installateurs Windows et Mac.

Le regroupement par rapport à la dépendance est un vieux débat dans le monde de l'emballage. Ce document parle de ces deux écoles de pensée: http://www.aosabook.org/en/packaging.html