State of the Gears

[Michael Pedersen]

I had meant to send this email over a month ago, and I apologize. This has been a rough time for me, personally. My new job doesn't fully approve of TG (they're a Perl and PHP shop, and TG, being Python, isn't exactly their framework of choice).

Back in the middle of January, we had a meeting with the core developers. Since we were using Google+ Hangouts, we didn't make it an open thing to everybody (only 10 people can join, after all). We covered a lot of territory, though, and it's high time we shared all of this with you.

We went over our progress last year. We noted that we did well on releases (we did get four new versions out after all). The status updates also did well, and during the ending of my time at the previous job, I stopped making them. I'll be resuming them shortly.

Not everything was well done, though: The Pyramid merger announcement was handled poorly. I'll discuss the future with Pyramid more thoroughly below.

We discussed what we want to see for this year, and I think our goals are more than reasonable. We want to get 2.2 out shortly (originally, we were thinking before Pycon, but I'm not sure we can after my absence of the past couple months). We want to get 2.3 underway, and we have some pretty decent sized plans for 2.3, and more on that below as well. We also have some plans for the website, some updates we want to see happen. We also want to find ways to expand the development team. We also discussed our need for Python3 support, though we don't have a firm timeline for that. Finally, we discussed the need for us to standardize on a JavaScript widget toolkit.

Our plans for 2.2 are as follows: We want to either make or integrate a Widget browser. We're looking to switch to ToscaWidgets 2 by default, since they're about to release a stable version. We want to reduce the number of packages we have to show in our PyPI, in particular by repoze.what-quickstart and repoze.what-pylons. We also want to merge in work by Chris Perkins to make Object Dispatch into an external package named Crank.

Our plans for 2.3 are as follows: Major speed improvements, possibly some backward incompatibilities will be introduced. We're planning on removing the dependency on Pylons entirely in this branch. Possibly we're going to replace the repoze.what/repoze.who packages as well as the default Authentication&Authorization mechanism.

Our directions of inquiry for Python3 are as follows: We're going to look at marrow as a possible replacement for Paste. The other option is to look at Pyramid's Paste Replacement. We'll also need to evaluate other libraries and modules, as not everything is supporting Python3, and we need to move forward soon.

For the JavaScript toolkits, we need to evalute Bootstrap, jQuery UI, and even Dojo. We did not come to a final decision at the time of the meeting, though it seems like we're going to settle on Bootstrap, based on recent conversations on the mailing lists.

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.

For the website, we have a lot of plans this year. We're going to change the front page again sometime soon, in particular to provide news feeds to help show activity. We're going to use dojotoolkit.org as a "model", if you will. They have a good layout, and we would be foolish not to use it when it clearly works very well for them. We're going to get some improved videos and screencasts, too. The docs are going to be made easier to update, so that when a push is done to them, it will automatically trigger a rebuild. We had issues with web-site speed, so we're going to check over the current speed and see if it can be (or needs to be) improved. The current CMS seems to have some issues that need to be worked out (in particular, while we can edit existing pages, adding new ones does not work right). Finally, we're going to look at adding an IRC web client.

The meeting was a good and productive one. We are moving, and I've seen plenty of evidence of that on the mailing list this year. I'm looking forward to another good year with this project.

--
Michael J. Pedersen

My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen

Google Talk: m.ped...@icelus.org -- Twitter: pedersentg

[Lukasz Szybalski]

Not everything was well done, though: The Pyramid merger announcement was handled poorly. I'll discuss the future with Pyramid more thoroughly below.

We discussed what we want to see for this year, and I think our goals are more than reasonable. We want to get 2.2 out shortly (originally, we were thinking before Pycon, but I'm not sure we can after my absence of the past couple months). We want to get 2.3 underway, and we have some pretty decent sized plans for 2.3, and more on that below as well. We also have some plans for the website, some updates we want to see happen. We also want to find ways to expand the development team. We also discussed our need for Python3 support, though we don't have a firm timeline for that. Finally, we discussed the need for us to standardize on a JavaScript widget toolkit.

Our plans for 2.2 are as follows: We want to either make or integrate a Widget browser. We're looking to switch to ToscaWidgets 2 by default, since they're about to release a stable version. We want to reduce the number of packages we have to show in our PyPI, in particular by repoze.what-quickstart and repoze.what-pylons. We also want to merge in work by Chris Perkins to make Object Dispatch into an external package named Crank.

Our plans for 2.3 are as follows: Major speed improvements, possibly some backward incompatibilities will be introduced. We're planning on removing the dependency on Pylons entirely in this branch. Possibly we're going to replace the repoze.what/repoze.who packages as well as the default Authentication&Authorization mechanism.

Our directions of inquiry for Python3 are as follows: We're going to look at marrow as a possible replacement for Paste. The other option is to look at Pyramid's Paste Replacement. We'll also need to evaluate other libraries and modules, as not everything is supporting Python3, and we need to move forward soon.

For the JavaScript toolkits, we need to evalute Bootstrap, jQuery UI, and even Dojo. We did not come to a final decision at the time of the meeting, though it seems like we're going to settle on Bootstrap, based on recent conversations on the mailing lists.

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.

 


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.

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?

Thank you,
Lucas

[Alessandro Molina]

This has already been discussed around an year ago, both in person, on
HangOut and many other ways, and we came to an agreement that didn't
prevent anyone from doing his own TurboGears like scaffold on Pyramid,
it just didn't have to be called TurboGears. Orion was the suggested
name at the time.

Now I don't see any point in bringing it up again, especially
considering that the 2.3 pylons less branch has been already under
development for 6 months, is now able to serve TurboGears applications
three times faster without any required change, works on Python3 and
has 1/3 of the dependencies we previously had.

That doesn't mean that TurboGears can't work with the Pyramid team, we
are in 2012 and most of the web frameworks are now build by many
independent modules that provide some kind of feature to the
framework. We will continue to share WebOb, Baker, WebHelpers, most of
the repoze stack and many other things.

It's just a matter of "would you like to replace 400 lines of custom
code with a library thousands of lines big that won't do anything new
and you will probably have to monkeypatch deeply like it happened with
Pylons?". TurboGears already broke code of its past users too many
times and doing it again would probably hurt the project a lot more
than not having written on our homepage that we are whatever
underlying framework based.

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears Trunk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/turbogears-trunk/-/55ZqKLBol6wJ.
>
> To post to this group, send email to turbogea...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-tru...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.

[Christoph Zwerschke]

Am 08.07.2012 21:20, schrieb Alessandro Molina:
> Now I don't see any point in bringing it up again, especially
> considering that the 2.3 pylons less branch has been already under
> development for 6 months, is now able to serve TurboGears applications
> three times faster without any required change, works on Python3 and
> has 1/3 of the dependencies we previously had.
>
> That doesn't mean that TurboGears can't work with the Pyramid team, we
> are in 2012 and most of the web frameworks are now build by many
> independent modules that provide some kind of feature to the
> framework. We will continue to share WebOb, Baker, WebHelpers, most of
> the repoze stack and many other things.
>
> It's just a matter of "would you like to replace 400 lines of custom
> code with a library thousands of lines big that won't do anything new
> and you will probably have to monkeypatch deeply like it happened with
> Pylons?". TurboGears already broke code of its past users too many
> times and doing it again would probably hurt the project a lot more
> than not having written on our homepage that we are whatever
> underlying framework based.

Agree with all points. Actually Pyramid is not such a huge library, it's
still pretty lightweight. Nevertheless, the core Pyramid docs is already
a 700 pages PDF file. People would have to use a framework where they
don't understand what's going on in the lower levels or they would have
to read these 700 pages just to understand the lower levels.

Also, if TG would make another radical change now, we would again come
into the situation where people start asking "shall I use TG2 now or
shall I wait for when TG3 based on Pyramid appears", and start wondering
whether they will be able to migrate their TG2 apps.

And then, the documentation would need to be adapted again etc.

Lastly, everything also depends on the time and energy the core
developers have at hand, and that is very limited. Mark, who orginally
came up with the plan of a merge, wasn't able to spend time for the
project any more. Currently only Alessandro and Michael are actively
working on the project. Maintaining what we currently and developing
that slowly and carefully is already enough work. I think they're doing
a good job, and I like that TG2 is moving more steadily now and less
jumping around with new ideas and changes every other week.

-- Christoph

[Michael Pedersen]

There's no doubt that other frameworks are bigger, more widely used, and more popular. No argument from me of any sort. Arguing in favor of a merger by stating "We have a better chance of taking down Django" is not a useful argument, though, not for me.

I don't devote the time I do to take down Django. I don't do it for money. I don't do it for fame. I don't even do it to help other projects improve, or reach any of those goals.

I do it because I love TurboGears. This web framework is the first one I ever found that actually made *sense*. I'd tried others. I'd even written my own really bad one in PHP in the early 2000's. None of them ever felt wholly right, though. Always, some aspect was poorly done, or some piece always got in the way of my project, or the entire system just seemed designed to make easy tasks complex, and hard ones virtually impossible. TurboGears provides something that others have always seemed to lack: just the right amount of simplicity.

When I go to work on a TurboGears project, I can navigate it easily. I can find and deal with the various pieces, and feel comfortable that I am actually finding what I need to find. When I need to make a change, I can feel comfortable that I am changing the right piece of code. TurboGears provides these things for me, and it makes coding with it into a joy.

Arguing in favor a merger on the grounds that everybody can topple the Django beast will not sway me. I love what we have, and I feel that the future is bright. It's not an easy row to hoe, to be sure, but few things worth doing are. All of that said, I'll address the rest of the points, and reply to everybody.

On Sun, Jul 8, 2012 at 2:28 PM, Lukasz Szybalski <szyb...@gmail.com> wrote:

Assuming that we did the merger work, we would have some piece of code called TurboGears that is based on Pyramid. Keep that in mind for these responses.

--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...

Unfortunately, this is not correct. We would be vulnerable to which specific version of Pyramid we coded against. If a benefit from Pyramid required changing the way we use an API, we could not gain that benefit until we updated the code. If a backwards incompatible change were made in Pyramid, we would have to update our code to fix it, or lock down which version of Pyramid we support. If we found a problem in Pyramid, we would have to rely on Pyramid to update before we could truly get it fixed. Furthermore, while Pyramid may be Python3 ready, we are not. Pyramid being ready or not has no bearing on whether our code is ready, and that's true regardless of anything else that may be going on.

This pro has some benefits, to be sure, but it's not the bed of roses that is painted here.

 

--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.

The same problems and benefits as the previous item.

 

--Any changes to Paste would already be done in pyramid.

While this is true, since we're not at that point in our own development. As such, this item is not a consideration for us at this time. In future, maybe, but right now, no.

 

--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. 

Agreed on this point. This would help Pyramid adoption, definitely.

 

--More consolidation would mean more of most common packages would be available to users. 

For consolidation, what I would actually look to provide is some way for modules to seamlessly make themselves available for multiple frameworks. For instance (and this may be a bad example), if we were to provide a "webframework.model" entrypoint, and all the frameworks were to honor it, then a given plugin could make it's model accessible without caring about who it's written for. That would allow for consolidation, without requiring that everybody join with a specific web framework or be invisible.

 

-- Instead of splitting from pylons embrace the evolution of pylons would mean more users are reassured tg2 is the right choice to build on.

Does it really? If someone is trying to make a choice, then wouldn't "Built on Pyramid" being on everybody's site be more of a vote for any users to go to Pyramid, instead? If the number of users mattered to me, this would actually be a detriment to TG, not a bonus.

 

Cons:
-- Some work is required to replace pylons components with pyramid

An unknown amount of work for a benefit that may not materialize for the TG framework. That's a high risk proposition to me. This particular item is a bigger detriment than I feel you give credit for it being.

 

-- Some tg.ext would need to be updated to support new changes.

Actually, many of them would. For instance, tgext.menu and tgext.xmlrpc (my own two) would probably be broken. tgext.admin stands a good chance of being DOA as well. And that's the major ones I can think of off the top of my head.

 

-- 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.

This "con" is also (albeit unintentionally) insulting. It makes a pair of assumptions that are not at all kind: We don't work outside of our comfort zone. We're incapable of taking TG to the next level.

Neither of those statements is true. Alessandro is working hard to prepare for Python3. I'm working on ideas that I can't even fully articulate yet (go read my G+ stream if you want to see). Our "comfort zone" is slightly restrictive, I admit. I prefer working with Python to working with Java. Outside of that, my attitude is "I have a problem. Now to solve it." I have no problem working on ideas that are decidedly not normal. I won't speak for others, but I'm pretty sure they feel the same.

As to whether or not we're capable of taking TG to the next level, that remains to be seen. It also remains to be decided what the next level *is*. If the definition is "massive following, dethroning Django", then no, I'm not capable of that. If the next level is "Making TG do things that others will look at, and be impressed, and ask me about TG and why I feel it's the best choice", then yes, I can do that. I have good ideas. They will happen.

 

-- Won't be able to "design" the new framework to replace pylons part, but rather will need to include already written software.

Not too much of a con either. After all, take a look at the number of packages we make available and use. We have too many libraries. I'd like to reduce our dependencies before we extend them again to include something else.

 

Would developers consider following the evolution of pylons and including pyramid into turbogears?

We have. We've considered it a lot. At one point, I even openly advocated for it, as much as I hated the idea personally. Why? I felt that it would be a good thing. And I started to leave the project behind, because it would no longer be the project that I loved. I saw no future for me with it. Then, thankfully, Christoph emailed me, personally, and asked me what my plans were. I had to confront my own issues with the merger, and I realized that, even though the merger could go on, that didn't mean that I, personally, had to. TG2 still had (and has) life in it.

I love it. Even with all the turmoil I've dealt with over the past year, I've loved this project. I kept coming back to it mentally. I want to work on it, work with it, and show people how great it is *right now*. I, personally, am not ready for a merger. I'm not going to be ready for a while, either.

That does not preclude collaboration. I can easily working with, and helping each other. We can figure out what we need to see by way of widget libraries, or database access layers, or whatever else. But for me, for now, the merger is not something I can get behind.

As it turns out, I reiterated much of what Alessandro said (though in more verbose form), so I'm not going to reply to him. No point :)

On Sun, Jul 8, 2012 at 4:48 PM, Christoph Zwerschke <ci...@online.de> wrote:

Also, if TG would make another radical change now, we would again come into the situation where people start asking "shall I use TG2 now or shall I wait for when TG3 based on Pyramid appears", and start wondering whether they will be able to migrate their TG2 apps.

One of the situations I want to avoid is one that happened early on in my involvement. 2.0 was going through a beta cycle, almost ready for release, but people on the ML and in IRC were telling everybody to go to the 2.1 that was still in development, not even at beta. This is not a good situation, and during any sort of merger period, that's where we'd be (well, unless we stopped everything for TG2, and declared it dead, while we release Orion/TG3. Obviously, that's not a good choice).

 

Lastly, everything also depends on the time and energy the core developers have at hand, and that is very limited. Mark, who orginally came up with the plan of a merge, wasn't able to spend time for the project any more. Currently only Alessandro and Michael are actively working on the project. Maintaining what we currently and developing that slowly and carefully is already enough work. I think they're doing a good job, and I like that TG2 is moving more steadily now and less jumping around with new ideas and changes every other week.

I've been slack for a long time. Work had a profound (and negative) effect on my personal life, and that limited my ability to self-motivate and work properly on TG. As you can see, that is changing a bit. The new job is decidedly healthier for me and for TG.

 

[jeetu]

Hi,
Thanks for such a nice discussion. It cleared many a things/confusions that I had on TG development. We have just started using TG and its really a good and clearly laid framework to develop upon. Speed developments in TG2.2(rc) are visible. The choice to include bootstrap is very well thought of (from the responsive design perspective). Template engines choice is also good. And sqlalchemy, wow. From a future perspective, I just want to say that when future versions of TG comes, my application should not break(other than few required minor changes to the code).

These are the things that matter to us rather that pyramid or something else at the core. Only thing,  is that making the core i.e proposed pyramid part itself pluggable may help, iff it does not deteriorate speed in a big way.

Thanks for TG.

[Mengu]

hi lukasz,

i am not a core developer but i call myself a TG evangelist so i
guess
i can say something about this.

as long as TG stays the same, i am not against building TG on top of
pyramid. however do we really need that? TG is already working fast
and smart enough. it has the libraries that we need for rapid
prototyping or building applications fast. i haven't needed anything
that doesn't exist in TG ecosystem but exists in pyramid's.

another thing is pylons, as we know it, is dead. there will only be
pyramid and pyramid users has a different understanding of
development. they are choosing the long way because pyramid is not a
full stack framework like TG. the ones who don't want to do it the
long way are either coming to TG or going to django.

from what you're saying i understand that you are not happy with TG.
please tell us why. because as our community grows on both IRC and
the
ML, we get requests and many of them are taken into consideration.
the
core developers are trying hard to build a strong application and a
happy community. because we believe we can pull it off.

[Mike Orr]

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 <szyb...@gmail.com> 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 <slugg...@gmail.com>

[Christoph Zwerschke]

Am 10.07.2012 19:38, schrieb Mike Orr:
> 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.

Yes, that was the crucial problem. Actually instead of Prototype and
Scriptaculous, TG1 used Mochikit, which was chosen for good reasons by
Kevin at at that time because it was a small, sweet and pythonic
library, but later it became obsolete as well :( Kid was not a big deal
because Genshi was pretty similar. SQLObject was a mich bigger problem.
And "non-WSGI" actually meant the CherryPy server which did not become
obsolete, but was replaced with Pylons anyway in TG2 (the TG1 branch is
still based on CherryPy). And there were even more components that were
replaced or were incompatible between TG1 and TG2 (authentication and
authorization, widgets etc.)

Both TG1 and TG2 were and still are great frameworks, but that
discontinuity was in fact kind of "traumatic" as you call it. Users had
problems because it was difficult to upgrade their old apps, newbies
became paralyzed because they did not know which version to choose, and
documentation was always lagging behind.

> The biggest worry of users is to go through a compatibility trauma
> again.

Exactly, TG2 is just in the phase of recovering from that trauma.

> 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.

This has been solved already. TG2 is slowly separating from the old
Pylons framework. Parts have been incorporarted into TG itself, parts
are replaced with (even faster) dispatch code (crank). TG 2.3 will
already be completely independant of Pylons.

> I have not heard anything about Orion besides rumors that it exists. Is
> it active?

No. It was an idea only, but it never materialized. Instead, TG2
developed slowly in a more natural way.

> I have long believed strongly in modularity, reusablilty, and
> interoperability. That's what led me to TurboGears, Pylons, and Pyramid.

Me too. And even if TG2 will not build upon the Pyramid core any time
soon, TG2 and Pyramid share a lot of components already.

-- Christoph