Sébastien Douche a écrit 83 commentaires

Mon Dieu, désolé pour les nombreuses fautes (faut dire que c'est un poil plus compliqué de se relire avec les accents qui passent mal à l'affichage).

Derrière cette fusion se cache une reconnaissance de la ZCA : Zope Component Architecture. Pylons, comme la plupart des grosses applications, deviennent difficiles à faire évoluer avec le temps. C'était la remarque faites par les core devs de Zope2 fin 90. Ils ont donc travaillé sur Zope3, qui au lieu de faire de l'héritage, utilisé la composition : l'objectif est de faire de petits composants autonomes, monotache, qui sont "collés" ensemble au moment ou c'est utile. Dans le monde Java, cela s'appelle l'inversion de contrôle, popularisé par Spring.

Dans le monde python, cela à donné les interfaces (zope.interface) et les composants (zope.component), qui permettent de développer avec de la composition. Zope 3 est évidemment le premier gros projet à l'utiliser. Avec le temps, certaines idées étaient bonnes, d'autres mauvaises (et en 10 ans, bcp de choses changent). Le projet Repoze BFG se veut être une simplification de Zope 3, en prenant les bonnes idées (dont la ZCA) et en modifiant certains points (le ZCML reste mais il possible d'utiliser du Python, utilisation possible de Routes à la place de Traverser, etc). Le principal développeur a fait un travail fantastique, en tant de terme de code (assez clean, 100% de couverture de test...) comme de doc (livre de 700p qui sort en même temps que la 1.0, site web trés complet), notamment en rendant la ZCA "invisible" pour le dev qui ne pas souhaite le manipuler directement.

J'attends beaucoup de ce projet, car il y'a 2 responsables de haut niveau, avec beaucoup d'années de lead development derrière eux. Et le fait qu'ils bossent depuis presque un an ensemble (reprise de code de l'un mais dans le projet de l'autre) me donne envie d'y croire. Et pour reprendre le titre, cela va donner dans le paysage Python :

- Django : 100% perso
- Pyramid, Pylons, Turbogears : ZCA, Routes, WebOb... Grosses réutilisations de composants Pythons reconnus. La différence se fera sur l'intégration ou non de fonctionnalités.

Une merveilleuse nouvelle pour le monde Python je trouve.

La semaine prochaine :)

> Quelque soit le langage, il est assez facile d'écrire du code incompréhensible.

j'ai jamais compris comment des développeurs (censés avoir un minumum de logique) sont capable de sortir un argument aussi ridicule.

Si on peut se crouter avec une 2CV comme avec une Mercedes, alors une 2CV et une Mercedes se valent.

Le monsieur parle de code lisible, pas de code illisible. Et la, yá une petite marge.

Salut Bruno,
je salue l'initiative et je mesure facilement l'ampleur de la tâche. Bravo à toi de tenter ce développement.

En fait je parle de tout :). Seulement de la théorie mais avec de nombreux exemples visuels à l'appui. Pour expliquer mon point de vue, la plupart du temps les présentations Git sont divisées en 2 (je schématise un peu) :

- présentation basique avec les commandes essentielles
- présentation avancée avec le fonctionnement interne

J'ai choisie une autre voie : parler de tous les concepts importants. Je parle donc autant des concepts dans le choix de de design (le backend par ex.), les concepts DVCS (le DAG par ex.) que les concepts d'implémentation spécifique à Git (comme les références).

C'est un donc balayage large qui a pour objectif de donner les clés de compréhension quand l'auditeur sera pour la 1ere fois devant son clavier :). Je parlerais donc autant de branches, de merge, de travail collaboratif...

Oui depuis plus de 2 ans (d'abord Hg puis Git). J'ai pu constater une amélioration *trés* importante, non seulement dans la qualité du projet mais aussi dans la diminution du stress pour les développeurs.

Trop long à expliquer (je ferai surement des billets sur le sujet) ici mais la multiplication des workflows (organisationnel, personnel et interpersonnel) est un gros plus. Sans compter bien sur la puissance fournie (rebase, cherrypick, merge bien plus simple, etc).

Bonjour Alexandre,
si tu es sur Paris, tu peux t'inscrire à la présentation Git de 2h que je fais le 30/11 :

http://www.doodle.com/hya5bs3bghcup9rv

L'objectif de cette pres est d'expliquer tous les concepts importants avant de se lancer. Suivra ensuite des ateliers d'initiation et de perfectionnement (j'en ferai peu par contre, car c'est bénévole et gratuit avec une limite a 20/25 personnes).

J'ai aussi commencé un blog sur Git : http://blog.gitfr.net

Peu d'articles pour l'instant mais le but est de l'enrichir en parallèle avec les formations.

Je l'ai étudié un peu et effectivement le concept général est intéressant, notamment le "cherrry pecking naturel".

>> MQ n'existe pas dans git... car c'est totalement inutile
> Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt
> (qui s'inspire directement des MQ) et bien d'autres.

Qui "on" ? Pas les développeurs de Git.

> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
>> Tu parles des branches légères ?

Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.

>> Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
> Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew
> Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002).
> Chronologiquement, ça ne colle pas ton histoire.

Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).

> La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les
> Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".

Les gens demandent aussi des poneys roses.


Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement. Hg a des avantages intéressants sur Git, mais surement pas dans la capacité de gérer un DAG ou de revoir un historique. Mais pour cela, il faut connaitre les 2 outils.

Un gros plus de Hg est la possibilité de développer des plugins maison, et cela *trés* simplement (merci Python). C'est quelque chose que j'ai perdu en passant à Git (faut wrapper la sortie, pas top) et cela me manque.

> Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur > maintient une serie de patchs par dessus le repository, et se ballade facilement avec des
> empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée
> en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière,
> de recommencer, etc... sans avoir fait le moindre commit.

J'ai utilisé Hg pendant 2 ans au taff (maintenant c'est git) , ou on employé tous MQ massivement (on a du produire des centaines de patchs) donc je connais assez bien. MQ n'existe pas dans git... car c'est totalement inutile. La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.

De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.

Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper. Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.

Désolé pour l'expression en anglais, cela veut dire effectivement à "prix réduit pour ceux qui achètent rapidement" ;).

Pareil, ca m'intéresse :)

Cela dépend de ce que tu appelles "beaucoup de ressources". Un serveur de base est maintenant un Intel Duo avec 2 go de ram, ce qui est largement suffisant et disponible à un cout largement accessible à une entreprise. En service, il existe beaucoup de fournisseurs en ligne pour un prix proche du php (http://plone.net/providers).

Maintenant, il est primordial de comparer la richesse fonctionnelle et non pas seulement sa "lourdeur" ! Un CMS PHP à iso périmêtre est bien plus lourd qu'une petite application PHP (bref, avoir Mambo ou SPIP en tête biaise la comparaison).

Je l'utilise depuis des années en permanence en entreprise dans ma palette d'outils (Plone, Trac, SVN ... sur une seule machine) et les performances sont plus qu'honorables. L'instance prend 150 a 300M et j'ai pas de soucis de vitesse avec plusieurs utilisateurs. Mais effectivement, Plone n'est pas "léger".

Précurseur ? Si je te dis que la 1ere version est sortie en 96 (libéré fin 98), tu en penses quoi ? :).

Oui clairement, avec Web Objects de Next (sorti aussi en 96), qui permet de développer une application Web un peu comme une application classique, au détriment d'une prise en main plus complexe que PHP 2 et 3 ou ASP (on doit penser objet, MVC, utilisation d'un ORM par défaut, la notion d'héritage à l'éxécution....).

Et puis, dans le monde Python, on faisait pas de pub. Il faut remonter à 2005/2006 pour voir un véritable début de communication (refonte du site web, création d'une ml marketing...) avec comme exemple RoR. Et c'est bien dommage, Python s'est fait bouffé par PHP alors qu'il avait bien plus d'atouts. Et Zope Corp. est le plus mauvais élève en la matière, avec un produit révolutionnaire, des core devs impliqués dans la vie de l'interpréteur, Zope est resté opaque (peu de doc, pas de livre...) et méconnu par beaucoup de monde, même dans le monde Python.

Et ca continue avec Zope 3, qui est une refonte from scratch. Y'a pas mal d'idées fort intéressantes, qui ne se trouvent pas dans les RoR, Tg, Django, qui sont "des versions modernes" de Zope 2 (dans l'esprit).

Bref, OVNI ou précurseur, les 2 mon capitaine. Et ca risque de pas trop changer, sauf si Plone arrive à démontrer la puissance du produit (ce qui est plutot bien parti avec Plone 3) sur les 2 prochaines années.

Euh, je ne vois pas en quoi mon mail était peu courtois. Dire que la procédure d'install est pas au point quand il existe pas de configure me parait pas saugrenu :). C'est même plutôt aberrant en fait de devoir lancer autoconf.

Un deuxième problème est que l'on ne peut pas avoir un Trac par projet. (je sais que c'est un problème spécifique, mais dans notre utilisation c'est un problème)


Euh, pas du tout, puisque je fais comme ça tout le temps. Un projet Trac peut pointer sur n'importe quel noeud d'une arbo SVN, la racine du dépot comme un sous répertoire. Donc si tu as un projet dans /mondépot/projet1/, tu donnes à Trac ce lien comme racine du projet et ça roule. Trac est vraiment très souple.

USVN part du constat que Subversion est un outil fantastique, mais qu'on n'utilise qu'une partie de ses capacités. Par fainéantise, on ne crée pas toujours un dépôt par projet, mais on met tout dans le même perdant ainsi la gestion de branche et de tags. On exploite rarement aussi la capacité de Subversion à donner des droits très fins sur un fichier ou un dossier du dépôt.


Ca ne choque que moi cette partie ? Quel est le rapport entre la création d'un dépot par projet et la gestion fine ? On peut avoir plusieurs projets dans le même dépot avec les branches / tags (heureusement). De même il est possible de gérer les droits correctement dans un seul dépot.

Pour moi la création de dépôts est plus de l'ordre de l'administration système (partition, sauvegarde...) ou du découpage fonctionnel de la boite (par client, par pole d'activité..) que technique.

Comme j'aime bien ce genre de jeu, j'ai décidé de tester. Et ben c'est pas de la tarte, faut déja installer Clanlib 0.8 sur Feisty (le configure oublie de vérifie la présence de plein de libs). Ok, 20mn plus tard, c'est bon. Mais aprés ca se gate :


./trophy: error while loading shared libraries: libclanGL-0.8.so.1: cannot open shared object file: No such file or directory


Bon normal, il cherche dans les répertoires lib tradi et non /usr/local/lib (qui aurait pu être ajouter à la compil mais bon). Donc c'est parti pour une compilation à la main :


sde@fou-hi:~/Desktop/trophy-1.1.4/trophy$ ./configure
bash: ./configure: Aucun fichier ou répertoire de ce type


Allons bon, pas de configure ni de Makefile (pourtant la doc indique de faire ./configure). Lançons un petit coup de autoreconf --install et :


sde@fou-hi:~/Desktop/trophy-1.1.4/trophy$ ./configure
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."


Bon ben tant pis, on verra ça quand ca sera dans les packages :).

Alors STP, donne-moi une raison cohérente avec ce que vous avez mis en place, car la tu donnes une argumentation qui n'a rien à voir avec le reproche que je vous fais.

Y'a des choses dont je n'adhère pas trop trop sur GCU, notamment ça. Mais je me marre toujours de voir des gens croire qu'un site web/chan irc/forum/whatever est du domaine public, ouvert et accessible à tout le monde, démocratie blah blah blah. Et ben non, c'est privé et les possesseurs font ce qu'ils veulent (du moment que cela respecte la loi bien sûr).

Ou tout simplement utiliser un plugin firefox qui extrait automatiquement les URLs de ce genre de site ;).

Nous avons toujours besoin de personnes de bonnes volontés ;). Si cela t'intéresses, tu peux toujours passer nous voir et découvrir comment cela se passe.

Moi c'est surtout Zope 2, Zope 3 et bientot Turbogears, avec un oeil qui louche quand même un peu sur Django.

Maintenant, pour l'afpy, il est bon de montrer que tout est accepté, même si pour des raisons évidentes (de temps, de personnes, de compétences), il est impossible d'avoir un parfait équilibre.

Juste un point, ne pas faire l'amalgame entre dév Web et Framework (beaucoup sont justement rebutés par ces derniers), mod_python par ex. n'est pas un framework amha :)

Un gros défaut, la vitesse: dixit un des dev que j'ai rencontré, PyPy est 10x plus lent que CPython, ils ont reussi a faire une pointe à 6.8x plus lent grace a je ne sais plus quoi.. Ca reste tres lent donc (enfin bon, ca s'ameliore, ca devait etre 30x plus lent au début, dixit le meme developpeur)

Effectivement, c'est encore lent mais il n'y a pas encore d'optimisation. Pour rappel, au départ PyPy était 1000x plus lent. puis 300x, puis 100x, puis 30x. Maintenant, il arrive selon le code à être entre 10x et 20x plus lent, avec un petit refactoring de quelques lignes :)

Le projet sprint (rassemblement de codeurs) à la fin du mois va surement donner un petit coup de fouet :
http://codespeak.net/pypy/extradoc/sprintinfo/mallorca/sprin(...)

Car le travail sur le compilateur Jit ne fait que commencer.

C'est un projet bigrement intéressant, qui risque de faire mal s'il va loin (avec l'intégration de Psyco et Stackless par exemple). Je conseille la lecture de :
http://codespeak.net/pypy/dist/pypy/doc/architecture.html

Mais d'aprés les auteurs, faut rien attendre avant fin 2006, surtout qu'il manque toujours la bibliothèque standard.