Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Cette remarque est valable aussi pour un passage à Pylons.
Pour le reste, il n'y a donc aucune raison objective à ce fork.
Je trouve ca dommage pour l'avenir de CherryPy car plus aucun framework haut niveau sérieux ne s'appuie dessus.
Par ailleurs, tu sembles indiquer que la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort puisqu'on se pose la question de l'intégration de CherryPy3 à la branche 1.x et non 2.x.
Ca casse un peu le mythe non ?
Dans ce cas, autant prendre un bon framework tout-en-un ala Django.
C'est une vraie question pas une tentative de troll.
[^] # Re: Plein de branches
Posté par nomorepost . En réponse à la dépêche Turbogears 1.1 le même mais en mieux.. Évalué à 6.
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Cette remarque est valable aussi pour un passage à Pylons.
Pour le reste, il n'y a donc aucune raison objective à ce fork.
Je trouve ca dommage pour l'avenir de CherryPy car plus aucun framework haut niveau sérieux ne s'appuie dessus.
Par ailleurs, tu sembles indiquer que la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort puisqu'on se pose la question de l'intégration de CherryPy3 à la branche 1.x et non 2.x.
Ca casse un peu le mythe non ?
Dans ce cas, autant prendre un bon framework tout-en-un ala Django.
C'est une vraie question pas une tentative de troll.