Je donne sa chance au produit.
Vraiment.
Régulièrement je retourne vers des technos que j’avais écartées pour voir comment elles ont évolué. Peut-être que c’est mieux. Peut-être que j’ai changé et que maintenant ça me parle.
Mais là, non ! Non, non, non !
Je m’en vais rejeter un coup d’œil vers buildout, un des premiers systèmes de build Python qui résout les problématiques de pip, virtualenv, cookiecutter et bien plus. Un couteau suisse robuste et polyvalent.
Je l’avais mis à la poubelle pour sa difficulté de mise en œuvre et sa doc pourrie. Un produit typiquement dans la philosophie de la communauté Zope dont il est issu : super puissant, super flexible, et aussi plaisant qu’un cactus dans le cul.
Réflexe logique, aller sur la page pypi, et dès le premier paragraphe je lis la description:
Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools
Je n’invente rien. Il y a quelqu’un qui a écrit ce texte en se disant que c’était pertinent. Il a dû être super content de lui le con. Je l’imagine en train de taper sur son clavier, mettant un point final à cette phrase un sourire aux lèvres. Fier. Le sentiment du devoir accompli.
Il avait raison sur un point : avec ce texte on sait tout ce dont on a besoin de savoir sur buildout, c’est-à-dire qu’il ne faut pas l’utiliser.
Au revoir.
P.S: je ne suis pas un demeuré, bien entendu que je suis allé plus loin et que j’ai passé du temps sur le site officiel. Je vous fais ici un résumé de ma pensée.
Ouais, Zope, c’est toujours, hum… underground ? Je sais pas trop comment dire ça…
Bref, j’utilise Plone tous les jours (vraiment), et donc buildout.
C’est dur, compliqué, avec de la doc éparse, et on ne sait jamais trop si elle est à jour, ni si elle est exaustive.
Par contre, oui, c’est puissant et flexible, on peut faire un paquet de bordel avec.
C’est mes yeux ou y’a des flocons de neiges sur le site ?
En soi buildout ne fait quasiment rien, tout le fonctionnement est déporté dans ses plugins (les recipes), et quand on a un problème avec buildout, c’est 99% du temps un problème lié à une recipe, ou à un egg, ou à un wheel, ou à distutils, ou à setuptools, ou à PIP, ou à PyPI ou à une dépendance système, etc.
Donc le vrai problème de buildout, c’est qu’il amplifie tout le merdier du packaging python en général… Et c’est vrai que sa doc est pourrie, et sa gestion des erreurs aussi.
@Jihaisse: c’est une option de WP qu’on a oublié de disable. Ca donne un côté Web de 1998.
T’es bien gentil. Moi, j’avoue, je vois une phrase comme ça sur un outil, je cherche pas plus loin…
Je dois dire que je n’ai pas compris. Quelqu’un peut m’expliquer en quoi la phrase pose problème ?
ok j’ai rien compris, ça parle d’un truc pour gérer les virtualenv etc…
Ce que je retiens de tout ça : buildout ça pue.
Cdt
avec ce texte on sait tout ce /donC/donT/ on a besoin de savoir sur buildout
“Il y a quelqu’un qui a écrit ce texte en se disant […]”
Bisous et merci pour votre taff.
Tu as testé Conda ? Il essaient aussi de résoudre les problèmes de pipes etc. C’est fait par les mecs qui font scipy et ça ne sert pas qu’à installer du Python. Après, de mon côté je n’ai pas essayé.
Oui, mais quel rapport ? C’est pas un article qui dit que je suis à la recherche d’un service de distribution.
@sam: Je sais que le but de ton article est de dénoncer la description merdique d’un produit, mais puisque tu parles de tester (ou pas d’ailleurs) un service de distribution (buildout), je te demande donc si tu as testé un autre service (Conda) et ce que tu en penses.
Après, peut-être que Buildout et Conda n’ont pas de rapport et je n’ai pas compris à quoi servait buildout… mais il me semble que c’est justement le sujet de l’article !
Buildout est un service de build. La force de conda c’est que tout arrive déjà buildé, justement.