Pylons et repoze.bfg fusionnent pour donner Pyramid

Posté par (page perso) . Modéré par patrick_g.
Tags :
17
17
déc.
2010
Python
Pylons et repoze.bfg sont deux frameworks web en Python ayant des caractéristiques semblables. Tous deux relativement légers et modulaires, ils intègrent autant que possible des composants existants. Ces deux frameworks fusionnent pour donner naissance à un nouveau framework appelé Pyramid, sous la houlette du projet Pylons créé à cette occasion.

Selon Ben Bangert, le créateur de Pylons, le code de Pylons était devenu difficile à faire évoluer et il s'est aperçu que bon nombre des changements qu'il souhaitait apporter était en fait déjà présents dans repoze.bfg. De son côté l'auteur principal de repoze.bfg, Chris McDonough, souhaitait désolidariser repoze.bfg du projet Repoze. Devant la pléthore de frameworks que la communauté Python a engendrés, tous deux souhaitaient également essayer d'inverser la tendance à leur niveau en regroupant le travail de leurs communautés.

À l'heure actuelle, techniquement parlant, Pyramid n'est rien d'autre que le code de repoze.bfg renommé et auquel sont ajoutées des fonctionnalités facilitant le portage d'applications Pylons. Pylons 1 va être maintenu, mais il n'y aura pas de Pylons 2. De même, le développement de repoze.bfg va s'arrêter à la version 1.3. Pyramid sera la continuité de ces deux projets. Cette fusion devrait permettre de voir prospérer une alternative solide à Django pour les cas où un framework modulaire est préférable à un framework monolithique.

Pylon est sous une licence type BSD et bfg sous licences BSD + ZPL.
  • # TurboGears -> TurboPyramid(?)

    Posté par . Évalué à 3.

    En voyant la nouvelle, j'ai été vérifier sur Wikipedia que TurboGears 2 était bien partiellement basé sur Pylons.
    La section parlant de futur de TurboGears mentionnant déjà la possibilité d'utiliser Pyramid comme base pour TG 3, il est même question de renommer le projet TurboPyramid.
  • # Join

    Posté par (page perso) . Évalué à 4.

    Preuve qu'il n'y pas que des forks dans le monde de l'opensource mais également des joins.

    Une preuve que les licences libres ne mènent pas uniquement à la multiplicité des solutions mais permettent également d'unir le meilleur de chacune dans une solution unique.

    Alexandre COLLIGNON

    • [^] # Re: Join

      Posté par (page perso) . Évalué à 3.

      Moi j'attends de voir les fork de Pylons pour assurer la pérénité des applications qui ne pourrons pas migrer ;)
      • [^] # Re: Join

        Posté par (page perso) . Évalué à 2.

        Personnellement je trouve que Pylons 1 est stable, le code est assez simple… je ne pense pas
        qu'il y ai besoin de fork pour cette version de Pylons.

        D'autre part, je ne pense pas que les actuels auteurs de Pylons soient contre la création de
        nouvelles versions pour corriger des bugs, des problèmes de compatibilités avec de nouvelles
        versions des librairies tiers…

        Par contre il faudra sans doute forker Pylons 1 si l'on souhaite y ajouter de nouvelles
        fonctionnalités mais je ne vois pas trop ce que l'on pourrait ajouter. Tout peut être fait avec des
        librairies annexes.
    • [^] # Re: Join

      Posté par . Évalué à 3.

      +1

      Dans le monde de Ruby on a eu la même chose avec Rails et Merb qui ont fusionné pour donner Rails3
    • [^] # Re: Join

      Posté par . Évalué à 1.

      Et je l'ai ajouté a wikipedia pour la postérité Fork (développement logiciel) :)
  • # La validité de la ZCA

    Posté par . Évalué à 8.

    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.
    • [^] # Re: La validité de la ZCA

      Posté par . Évalué à 1.

      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).
    • [^] # Re: La validité de la ZCA

      Posté par . Évalué à 3.

      Mouais... tout ça c'est du wishful thinking basé sur des lubies technologiques, à mon avis.

      La grosse différence entre, d'une part, Django et, d'autre part, le monde Pylongs/TurboGears/Pyramid/repoze/etc., c'est que Django a une communauté.
      Or, si Django a une communauté, c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique, à fusionner ou forker dans tous les sens. Ils se soucient avant tout de rendre le meilleur service possible à leurs utilisateurs, pas d'avoir une architecture top-moumoute avec des composants décentralisés et des buzzwords hérités du monde Java.
      • [^] # Re: La validité de la ZCA

        Posté par . Évalué à 5.

        Salut Antoine :)

        > tout ça c'est du wishful thinking basé sur des lubies technologiques, à mon avis.

        Je te trouve bien sévère. Vouloir améliorer les choses est une lubie ? Se retrouver devant un problème de maintenance est une lubie ? J'ai du mal a comprendre.

        > c'est que Django a une communauté.

        Ils ont tous une communauté.

        > Or, si Django a une communauté, c'est précisément parce qu'ils ne passent pas leur temps à
        > changer de plateforme technique, à fusionner ou forker dans tous les sens.

        RoR est un contre exemple, Linux aussi. Ton argument me semble hors de propos, Pylons a maintenant 6 ans ! De plus, Zope3 ou Pylons rend de bons services que Django ne peut pas rendre. M'enfin, si la qualité ou l'intérêt se mesure à l'ampleur de la communauté, je suis au regret de dire que le projet sur lequel tu bosses est une lubie face a PHP et Java.

        > ls se soucient avant tout de rendre le meilleur service possible à leurs utilisateurs
        > pas d'avoir une architecture top-moumoute

        C'est évident, ils ne refactorent jamais, ne changent rien, jamais. ET puis prendre en exemple un projet qui a *tout* recodé (parce que les trucs des autres, c'est pas assez bien), c'est rigolo je trouve.

        > buzzwords hérités du monde Java

        C'est un argument ça ? (Zope3 et Spring Framework sont sortis en même temps, je donnais juste un élément de comparaison). Ta réponse me fait plus penser a une critique gratuite qu'autre chose.
        • [^] # Re: La validité de la ZCA

          Posté par . Évalué à 2.

          > c'est que Django a une communauté.

          Ils ont tous une communauté.


          Non justement... Sur les listes de TurboGears il y a quelques pékins, le développement fonctionne par intermittence, le code est en perpétuelle qualité alpha. Je n'ai pas l'impression que Pylons ait été beaucoup plus actif.

          C'est bien le problème, pas la relative supériorité technologique de telle ou telle approche.
      • [^] # Re: La validité de la ZCA

        Posté par . Évalué à 5.

        > c'est que Django a une communauté.

        Pylons/TG aussi.

        > c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique
        La force de Django est de proposer effectivement un framework cohérent donc plus facile à apprendre, une documentation centralisé etc... mais c'est également sa plus grande faiblesse.
        * les composants Django pris séparément sont pas toujours au niveau de la concurrence, je pense entre autre au Django ORM (une bouze extrêmement limité comparé à SQLAlchemy ou Storm) ou au module d'authentification.
        * la difficulté à utiliser un composant tiers comme un autre ORM ou moteur de templates.
        * c'est quasiment le seul framework web Python qui ne supporte PAS la norme WSGI ! Je ne parle pas de la capacité à être servi par un serveur WSGI mais de la possibilité de chainer les middlewares. Django se prive de la possibilité d'utiliser des composants éprouvés notamment pour l'authentification, le caching etc ... Certes, il y a les apps (l'équivalent côté pylons/TG serait plus ou moins les widgets du projet ToscaWidgets qui est en retrait par rapport aux Django Apps) pour permettre la réutilisabilité du code, mais ça reste un mécanisme limité.
        * quelques bizarreries: gestion des settings
        * aucune attention porté aux performances qui ne cessent de diminuer au fur et à mesure des versions, si je veux un site qui monte en échelle (genre Sourceforge), je peux oublier Django.
        * la communauté Django est très active et amicale, les core developers not so much ...

        Je pourrais faire une liste aussi longue pour Pylons/TG, tout ça pour dire que le choix d'un framework web python n'est pas aussi évident.
        Si je suis un développeur web qui souhaite proposer à ses clients des sites riches avec un TTM le plus réduit possible, je m'orienterais naturellement vers Django, je suis un développeur Python chevronné mais qui n'a pas forcément fait du web, je m'orienterais vers Pylons/TG qui me permettra de réutiliser mes connaissance, je veux un framework minimaliste, j'utiliser un micro-framework (ie: Flask/Jinja2, web.py, repoze.bfg, etc ...) ou même une boite à outils comme werkzeug !

        > c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique, à fusionner ou forker dans tous les sens.

        Les fusions ont toujours été soigneusement réfléchies et résultent toujours d'une convergence des roadmaps des développeurs. Pourquoi réinventer la roue à chaque fois ?
        Mis à part le passage de TG1 -toujours maintenu actuellement- à TG2, il n'y a pas plus d'incompatibilités lors des changements de versions chez Pylons ou TG qu'avec Django.
        Dans le cas de Pyramid:
        * porter une application Pylons à Pyramid ça va de "rien à faire" à "quelques changements mineurs qui peuvent être automatisés". Un outil de migration est prévu d'ailleurs.
        * pour les applications repoze.bfg, mis à part le changement de nom et une réorganisation des modules, y a rien à faire.
        * j'ai ouï dire qu'il a fallu moins d'une journée pour avoir un prototype fonctionnel de "TG3" et qu'une application TG2 pouvait tourner quasiment sans modifications dessus.
        Certes, le schéma de migration de Django est certainement mieux contrôlé, mais rien de catastrophique non plus. De plus, les fusions permettent justement de limiter ces problèmes.
        Quant aux forks, ils sont assez peu nombreux et pour la plupart confidentiels.

        > pas d'avoir une architecture top-moumoute avec des composants décentralisés et des buzzwords hérités du monde Java.

        Même si Pyramid est un lointain descendant de Zope à travers repoze.bfg (c'est bien, ça va donner matière à troller lors des afpyros), la réputation de lourdeur que se traine Zope ne se justifie plus du tout pour les composants repoze issus de la restructuration de Zope en middlewares WSGI.
        • [^] # Re: La validité de la ZCA

          Posté par (page perso) . Évalué à 2.

          repoze.bfg un microframework? Tu es sûr?
          • [^] # Re: La validité de la ZCA

            Posté par . Évalué à 2.

            Si tu considéres que Pylons en est un à la base et que repoze.bfg est encore plus petit oui.
            Plus petits, tu as (l'excellent) Flask ou à la rigueur web.py mais en deçà, c'est des boites à outils (werkzeug, cherrypy etc ...)
          • [^] # Re: La validité de la ZCA

            Posté par . Évalué à 1.

            Ce n'est pas un micro framework a mon sens, même s'il est trés léger. Par contre, sa fléxibilité lui permet de se comporter comme un micro framework. Cf sa série Groundhog :

            - Groundhog (Building a Microframework with BFG) #1: Mapping URLs to Code
            - Groundhog (Building a Microframework with BFG) #2: URL Generation
            - Groundhog (Building a Microframework with BFG) #3: HTML Templating
            - Groundhog (Using BFG to Build a Microframework) #4: Sessions and Flash Messages
            - Groundhog (Using BFG to Build a Microframework) #5: Exception Handling
            - Groundhog (Using BFG to Build a Microframework) #6: Events and Context Locals

            Disponible sur le blog Repoze (http://blog.repoze.org/).
      • [^] # Re: La validité de la ZCA

        Posté par (page perso) . Évalué à 1.

        > Mouais... tout ça c'est du wishful thinking basé sur des lubies technologiques, à mon avis.

        Ces "wishful thinking basé sur des lubies technologiques" existent et fonctionnent.
        Ce n'est pas du vaporware.

        > La grosse différence entre, d'une part, Django et, d'autre part, le monde Pylongs/TurboGears
        > /Pyramid/repoze/etc., c'est que Django a une communauté.

        Pylons a une communauté. Plus grande ou moins grande que Django c'est difficile à dire car :

        * la communauté Pylons englobe la communauté SQLAlchemy, Mako, Routes, Jinja2, WSGI… en résumé englobe la communauté Python - Django
        * la communauté Django est un peu repliée sur elle même

        Certes, ces arguments ne sont pas à prendre au pied de la lettre mais l'idée est là.
        Je tiens à signaler au passage que j'aime bien Django, j'aime bien tout ses outils hauts niveaux
        que je ne trouve pas dans Pylons…

        Cependant j'aime la liberté que me donne Pylons : j'utilise les librairies que je veux et
        si possible les meilleurs dans leurs domaines.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.