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

10

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.

package-management

— VPeric
source

Vous devez fournir plus d'informations sur votre situation spécifique pour obtenir une meilleure réponse. Par exemple, quel environnement prévoyez-vous de l'exécuter? Sera-t-il exposé à Internet?

— tshepang

Votre application est-elle open source?

— Anton Barkovsky du

@Anton Oui, c'est SymPy , une bibliothèque Python open source pour les mathématiques symboliques. J'y travaille en tant qu'étudiant GSoC (divulgation complète :)).

— VPeric

@Tshepang La discussion peut être consultée sur: code.google.com/p/sympy/issues/detail?id=2482

— VPeric

@VPeric: Il serait très agréable de résumer cette discussion, juste pour gagner du temps pour ceux qui souhaitent répondre à votre question.

— tshepang

5

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.

— Patrick
source

1

C'est un point important, et c'est en partie pourquoi de nombreuses distributions n'aiment pas avoir des bibliothèques regroupées avec des programmes; par exemple, Debian a pour politique de ne pas regrouper une bibliothèque avec un exécutable ou de lier statiquement une bibliothèque à moins qu'elle ne puisse jamais être utilisée que par ce programme particulier (ou, pour la liaison statique, les cas où la liaison dynamique n'est pas prise en charge).

— Gilles 'SO- arrête d'être méchant'

En fin de compte, c'est peut-être le point le plus important. Je suis également d'accord avec les autres réponses, mais je n'ai dû en choisir qu'une. :)

— VPeric

6

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.

— tshepang
source

1

Tous les bons points. Je suppose que cela pourrait être lu comme "à l'épreuve du temps": peu de vos points s'appliquent actuellement (mpmath n'est utilisé que dans quelques autres projets pour le moment), mais il est facile de voir que chacun de vos points gagne en valeur pour chaque nouveau projet en utilisant mpmath.

— VPeric

4

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.

— Anton Barkovsky
source

Pouvez-vous expliquer le dernier point. Je ne peux pas dire si c'est un argument pour / contre le regroupement.

— tshepang

3

Je le comprends par opposition au regroupement - les utilisateurs veulent installer ce qu'ils veulent, pas me forcer une version particulière sur eux.

— VPeric

3

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.

— Shadur
source

3

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.

— Michael Ekstrand
source

1

Bien que je sois d'accord en général, cela crée un fardeau supplémentaire (même faible) qui signifie que probablement personne ne soutiendrait cette solution.

— VPeric

2

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

— Éric Araujo
source

2

C'était une lecture intéressante, mais elle parle plus des détails d'implémentation et des différentes spécificités de Python que de la philosophie générale.

— VPeric