Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
* chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).
* ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.
Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 10.
Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
* chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).
* ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.
Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.