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.
Aller plus loin
- Pylons, le projet (58 clics)
- Pylons, le framework (35 clics)
- repoze.bfg (38 clics)
# TurboGears -> TurboPyramid(?)
Posté par jfmartin . Évalué à 3.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 4.
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 LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Join
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
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 Hojo . Évalué à 3.
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 djano . Évalué à 1.
# La validité de la ZCA
Posté par Sébastien Douche . Évalué à 8.
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 Sébastien Douche . Évalué à 1.
[^] # Re: La validité de la ZCA
Posté par Antoine . Évalué à 3.
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 Sébastien Douche . Évalué à 5.
> 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 Antoine . Évalué à 2.
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 GeneralZod . Évalué à 5.
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 rhizome . Évalué à 2.
[^] # Re: La validité de la ZCA
Posté par GeneralZod . Évalué à 2.
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 Sébastien Douche . Évalué à 1.
- 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 Stéphane Klein (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.