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

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

[Alessandro Molina]

Just for notice, most of the discussion has been brought on the
turbogears-trunk mailing list where it probably relies most, people
interested can follow the discussion there.

> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
>