Hi all. Lukasz asked me for feedback on the question of converting TurboGears to Pyramid. I should start by saying that although I'm involved in Pyramid and Pylons development and know a few TG developers, I've only followed TurboGears at a distance, and not since Orion was floated a year ago. So my perspective is more historical and long-term.
Kevin's original vision for TG was to select best-of-breed components and integrate them into a framework. That was an excellent idea and inspired me personally, but it failed in the sense that all his original decisions became obsolete: Kid, SQLObject, Prototype and Scriptaculous, non-WSGI base. To be fair, WSGI came out after TG was created and raised the bar on what a framework should be. All frameworks at the time went through a difficult conversion. I used TG (pre-1.0) for a short time, but it was not stable enough at the time so I switched to Pylons. The developers knew before 1.0 that it would need a restructure, and so 1.0 was released as the "old code" while work progressed on a new base -- after some experiments like RhubarbTart, eventually Pylons was chosen as the base. The conversion to 2.0 was particularly traumatic on the user base, who felt that they'd adopted shiny new 1.0 and bought the book and in less than a year it was obsolete. On Sun, Jul 8, 2012 at 11:28 AM, Lukasz Szybalski <[email protected]>wrote: > > >> >> >> For the Pyramid merger, most of us who are using TurboGears are happy >> with the direction things are going for TG. After discussion, we came to >> the consensus that the product built on top of Pyramid that provides a >> TG-like layer should not be called TG3, but rather Orion. We're also >> leaning towards not promoting it as the evolution of TurboGears. TG isn't >> perfect, but we're happy with it, and want to continue to extend it, >> improve it, and make it vibrant again. >> > > > This sounds like a sensible solution to me. The biggest worry of users is to go through a compatibility trauma again. It may be feasable to make a 100% compatible API on top of Pyramid, but inevitably something or other will slip through and cause extra work for users. Also, the conversion of Pylons to Pyramid showed that the developers will end up adopting some new APIs as superior to the old ones, thus forcing the users to do so too. Either way, it means modifications to applications. If it's desired to retain compatibility *and* move into the future, then doing the former under the TurboGears name and doing the latter under a new name makes sense. Since Pylons is "lightly maintained" at this point, it would behoove TG developers to step up to maintain it and perhaps plan a Pylons 2.0. I have not heard anything about Orion besides rumors that it exists. Is it active? > To: Trubogears2 steering committee/TG2 Core developers > > My goal of writing today is to convince TG2 core developers to reconsider > their plans for not using pyramid, embrace the new changes in > pylons(pyramid), and reconfirm the state of the union between turbogears2 > and pylons project. Turbogears2 pylons backbone was a great success, it > consolidated python web frameworks, and provided a bigger community to > compete with others like django, ROR and was probably the perfect choice to > develop web applications fast. > Now 3 years later Turbogears2 (1K Downloads since 04/2012) is still strong > but pylons (11K Downloads) have merged with repoze.bfg(3K Downloads) to > create pyramid(14K Downloads since 05/2012), which merged the web > frameworks even more and brought over some of zope/plone community with it. > What these number mean for turbogears future is that if tg2 reconfirms > their ties to pyramid, it might become one of the most powerfull contender > to django (212K downloads). > > What are some pro's and cons with following pylons evolution: > > Pro: > --Features that pyramid is capable of would work by default in turbogears, > no rewrite of code would be required to take tg2 into python3 for example, > take the speed improvements, etc... > --All the components that were mentioned above from repoze.XXX would still > be valid and would follow pyramid upgrades and no additional work would be > required to get them working. > --Any changes to Paste would already be done in pyramid. > --Turbogears choice of most downloaded components as a default would bring > over few users that have high learning curve because of pyramid default > scaffolds selections. > --More consolidation would mean more of most common packages would be > available to users. > -- Instead of splitting from pylons embrace the evolution of pylons would > mean more users are reassured tg2 is the right choice to build on. > > I have long believed strongly in modularity, reusablilty, and interoperability. That's what led me to TurboGears, Pylons, and Pyramid. My sense is that Pyramid has a strong and flexible base. It can "go with" users to whatever gee-whiz technology may appear in the future. Its flexibility is also helpful when an application's direction changes; e.g., when it needs more nested-URL traversal-like features, or plug-ins via interfaces, etc. You can start using or stop using these features at any time, without having to rewrite your application to a totally different framework. My vision is that all (non-tiny) Python frameworks would become Pyramid-compatible, and that would lead to maximum interoperability for users. Pyramid also has a thorough reference manual and API documentation. These were things missing in Pylons, so by adopting Pyramid we got them "for free". Of course, Pyramid's beginner documentation is less than desired, but at least the reference docs are there when you need them. (And somebody is revamping the Pyramid docs this summer, so the next version may be much better.) > Cons: > -- Some work is required to replace pylons components with pyramid > -- Some tg.ext would need to be updated to support new changes. > -- Core developers would have to go a little outside of their comfort zone > by not just "being happy" with current state of tg2 but to take it to the > next level. > -- Won't be able to "design" the new framework to replace pylons part, but > rather will need to include already written software. > > TG won't be perfect with pyramid at its core but I think a lot more users > will be happy with it, and want to continue to extend it, improve it, and > make it vibrant again. > > Would developers consider following the evolution of pylons and including > pyramid into turbogears? > > I assume that there's no technical blockage in making a 100% compatible TG API for Pyramid. The most difficult part would be the magic globals / StackedObjectProxies. Would they return the Pyramid request/response or subclasses? Would you use Pyramid's routing or plug in Routes (which could be done by overriding the dispatcher class to delegate to Routes). But this quickly gets into whether it's worth making compatibility layers rather than forcing users to adopt the slightly different Pyramid Request/Response/add_route. If the existing TG codebase is still supported, there's no reason to, because only those willing to adopt the new APIs will use the new codebase. Another question is whether the developers are really willing to maintain two codebases equally. Are there enough "classic TG" developers *and* enough "TG/Pyramid" developers? If the classic developers are more numerous, Orion will never get done. If the future-pushing developers are more numerous, they'll jump ship and "old" TG will be lightly maintained like Pylons was. That will irritate users who will grumble, "TG broke compatibility a second time." So I don't know the answer there; it really depends on how many developers want to do the one vs how many want to do the other. Also, there are now several high-level frameworks in Pyramid. Ptah claims to be Django-like. Kotti is a content management system that can be extended. Is there a need for a TG-like framework different from Ptah? Would it be possible to join or work with an existing Pyramid-based framework rather than creating a new one? Anyway, I can't say what's right for TG but I hope its innovation continues as it has done in the past, and these are some questions I would ask about potential future directions. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
