TG2 release plan thoughts
Mark Ramm
and that we work together to get a release candidate by the end of the
year.
We're very close, but if the next release is going to be 2.0 there are
a half dozen tickets that should be completed, and we need to polish
some stuff up including docs, testing, and polishing up the TG2
index.
Because it's critical that we get this stuff out the door, i'm hoping
to recruit a few people to help. There are a lot of places where
people with a few hours to help, and a desire to see a modern
full-stack component based framework succeed.
TurboGears 2 is somewhat uneque in the modern web framework space in
that it attempts to provide solutions for the archetectual problems
that limited sites like Pownce, Twitter, and TG1 sites, that I've
worked on in the past.
TG2 provides an industrial strength framework that solves real
problems like multi-database support, supports for horizontal
partitioning (sharding) and other database scaling strategies. I'm
about to release my first TG2 site into production at Compound
Thinking, and it's provided a great platform, even while it was in
beta. But, It's time to make things happen, and get a release out
there and start letting people know about all the great work that has
gone into this by Florent, Gustavo, Luke, Dan, Jorge, Chris P, and
many others, as well as the great work done by component developers
like Mike Bayer, Ian Bicking, and Ben Bangert (to name just a few).
The core development team has some work to do increasing test coverage
and getting things ready for a release and anybody who wants to help
out should jump in and let us know.
But in order for the release to go as well as it should we need some
help from the rest of the community. We need to provide the best
possible experience for people who come to try TG2 out in the new
year. And that means:
1) Great docs
2) Nice people on IRC and the mailing lists
3) Quick turnaround on bug reports
To that end, I think we should put together a "support team" in place
to help monitor IRC, the mailing list, and the doc-comments RSS feed
to make sure that questions that get raised get answered -- and that
the answers get put into the official docs. This doesn't mean that
you need to have the answers to TG2 questions, nor does it mean that
you have to hang out on IRC and answer questions all the time, just
that you'll help to take the initiative to match up questions with
developers who can answer them and ultimately to make sure that the
answers get recorded.
If you're interested in joining this support team, please let us know.
If you think you can help get it organized and make sure that it
runs smoothly defintely let us know.
I'd also love to have a couple of people who are interested in helping
out with the TG2 docs. I've put a lot of work into things myself,
but sometimes it's hard to see what's missing when you're too close to
the problem. So, someone who can point out the missing links is
helpful, and it would be super helpful if we had some better docs for
FormEncode schemas, and complex widget form stuff. So if you're
interested in joining the docs team, let us know.
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Derick Eisenhardt
As a user, I tend to think of using TurboGears as not only a
framework, but kind of like a full out distribution. I prefer to use
the packages you guys include in your own repo, rather than pull
individual components myself to make sure it's all as stable as
possible.
I'd love to see a final/stable release for 2.0, however I would ask
you to please hold off at least until all your dependencies have their
own stable releases. Most importantly SQLAlchemy and Pylons, which are
both in beta/RC phases still. I'm sure we're still a few months away
from TG2.0.final anyway, so hopefully this won't even be an issue by
then.
Thanks to all of you, it has been a pleasure working with the alphas
and betas so far ;)
- Derick Eisenhardt
Mark Ramm
> you to please hold off at least until all your dependencies have their
> own stable releases. Most importantly SQLAlchemy and Pylons, which are
> both in beta/RC phases still. I'm sure we're still a few months away
> from TG2.0.final anyway, so hopefully this won't even be an issue by
> then.
I actually think both SA and Pylons are in the RC process now, so
there should be no API changes, only bugfixes between now and stable
releases. So I don't think we should stop trying to get TG2 ready
for final to wait for them... But you're right, if we can't get
stable pylons and SA releases, we may need to hold off on the final
TG2 release for that.
--Mark Ramm
Christoph Zwerschke
> If you're interested in joining this support team, please let us know.
> If you think you can help get it organized and make sure that it
> runs smoothly defintely let us know.
It's good to see TG2 making progress. So far I've focused on TG 1.x
which I'm using for my productive apps, but I'd also like to work
with/on TG 2 in the future. I think the main reason why I didn't really
look into TG 2 so far was that I never used Pylons, so I feel I first
need to get aquainted with Pylons, but haven't found the time so far. It
would be nice to have a kind of Pylons crash course available, or a
"everything a TG user needs to know about Pylons" article. Maybe
something like this already exist? Can you give a good starting point
and roadmap for learning Pylons and TG 2?
-- Christoph
Mark Ramm
> look into TG 2 so far was that I never used Pylons, so I feel I first
> need to get aquainted with Pylons, but haven't found the time so far. It
> would be nice to have a kind of Pylons crash course available, or a
> "everything a TG user needs to know about Pylons" article.
This is a great idea, and I'll write something like this this week sometime.
--Mark Ramm
Derick Eisenhardt
On Dec 8, 11:58 pm, "Mark Ramm" <mark.mchristen...@gmail.com> wrote:
> I'd like to propose that we declare the next stable TG2 release 2.0
> and that we work together to get a release candidate by the end of the
> year.
2.0.0.beta1 next right?
Mark Ramm
Seems about right, and that was the plan.
Though I'm not opposed to keeping the numbering scheme we have now
until the stable release becomes 2.0.
--Mark Ramm
Lukasz Szybalski
I think the 2.0 is a great idea but I would put some pressure on
Pylons to release the 1.0 version. They seem to be taking forever on
the 0.9.6. I'm not sure but the last time I've checked (6 months ago )
the only thing that needed to be done was docs. It seemed then it will
take max a month to make a 1.0 release. It seems to me they are
holding back. I'm not sure if there are any developers here that are
also active on pylons and can talk to people in control to release a
1.0 and work on 1.0.1. It seems to me that pylons won't be changing
much in a next 6 months and they are just floating. I think making a
1.0 release would give a boost to them and make the tg2 available!
Can we start a discussion on pylons devel about that? Based on their
roadmap (http://pylonshq.com/project/) there doesn't seem to be any
major bugs to incompatibilities. That is my impression. If they say
they won't release 1.0 until routes 2 , new webhelprs and pylonsbook
comes out and if it will take more then 2 months then we should
release a turbogears 2.0.
As far as sqlalchemy, they are on a strict schedule of releases and
after they went into 0.5 it seems as they will continue on a steady
path. It seems to me that 0.5 is as stable as it gets, we should not
wait just so we can see a different number. It was stable year ago and
it is stable now.
Thanks.
Lucas
Timur Izhbulatov
Christoph,
I feel that my impressions of learning TG 2 are getting stale. I'm
going to share some random notes with you (and everybody else) before
it's to late... :) Sorry for long email.
Like you, I had been already using TG 1 for a while when I decided to
give TG 2 a try. This September I started working on a simple TG 2
application. It needs neither auth{entication,orization} nor database,
so I'm not discussing these here.
I would recommend starting from the official docs. In particular,
Getting Started with TurboGears and Tutorials were very helpful. There
were some example code snippets not working as is, but it was pretty
easy to figure out the problem and, probably, some or all of them are
fixed now.
Get familiar with WSGI if you aren't already. TG 2 was my first WSGI
framework. I tried looking at WSGI maybe few years ago. I read the PEP
(OK, everything looks pretty simple), took a look at pythonpaste.org
(what is this all about?!) ... and failed to get started with this
technology. But thanks to TG 2 now I have an idea how WSIG can be used
in practice.
Another good thing is that TG 2 has very small and code base written
in decent PEP 8 Python! I would recommend reading configuration.py
[1] first. This is the heart of the framework where all WSGI set up
happens. This module gives you a good idea of how TG 2 uses all
third-party components, and therefore how you can customize this in
your app. Other notable parts are controllers.py [2] and decorators.py
[3] telling you more details about object dispatch, validation,
rendering and some i18n.
Surprisingly, as of my impression TG 2 is not that much of Pylons from
application developer's perspective. TG 2 is more like a higher level
built *on top* of Pylons, so some concepts/recipes from the later are
not directly usable (decorators, for instance). And without looking at
the source code it's not always clear which things should be imported
from tg and which from pylons or somewhere else.
Decorators are *very* different from TG 1. Actually, now they are much
cleaner and use no magic — it's just hooks. To my knowledge, there's
no any examples in the official docs yet but I have some in my app
[4].
i18n tools are better and easier to use than in TG 1. However, in
general i18n still needs some workarounds [5].
I think the most difficult part of the learning process was
ToscaWidgets. This is a very powerful but complex framework, and when
you start using it, you quickly exhaust the material available on the
official site and in TG 2 docs. However, the source code is also
rather clean and reading some parts of it helped me a lot.
Best Regards,
Timur
[1] http://trac.turbogears.org/browser/trunk/tg/configuration.py
[2] http://trac.turbogears.org/browser/trunk/tg/controllers.py
[3] http://trac.turbogears.org/browser/trunk/tg/decorators.py
[4] http://code.google.com/p/posy/source/browse/trunk/posy.tg/posy/tg/lib/decorators.py#23
[5] http://groups.google.com/group/turbogears-trunk/msg/21e0e32f43ea4e25
--
Timur Izhbulatov -- www.timka.org
Iain Duncan
I'm +1 on that. I think major release numbers create a lot of
expectation in terms of polish and that it is a big marketing no-no to
rush the major release numbers.
my two cents
Iain
Florent Aide
>
>> > I assume this means rather than TG 1.9.7.beta3, we'll be seeing TG
>> > 2.0.0.beta1 next right?
>>
>> Seems about right, and that was the plan.
>>
>> Though I'm not opposed to keeping the numbering scheme we have now
>> until the stable release becomes 2.0.
>
> I'm +1 on that. I think major release numbers create a lot of
> expectation in terms of polish and that it is a big marketing no-no to
> rush the major release numbers.
I have the exact opposite opinion here: We have 1.0.x, 1.1, 1.5 and
1.9 branches... I strongly feel 2.0 should be identified as such. If
we enter a cycle of "beta" versions we will then have a possible "rc"
cycle. This means we have some margin before we label TG2 as stable.
We need to remember TG2 was actually announced at least one year ago
in great fanfare, the evil is already done and I prefer having a
2.0beta with some quirks than people calling tg2 vaporware. At the
moment tg2 _is_ vaporware for the vast majority of python users out
there. I have been in a lot of python enthusiast meetings, the people
I met there were surprised that TG2 actually existed!
TG2 does not exist, TG2 does not have a presence, if we continue to
hide TG2 behind a 1.9.xxbetax versioning scheme we're just finding
excuses to not release the damn thing and to fail silently.
I have invested time and effort in TG1 to maintain the platform
waiting for TG2 to mature, I have invested time and effort to help TG2
get closer to a release when/where I could, but I feel now is the good
moment to start going public and to start pushing the thing out. If we
don't do it now we won't do it ever.
Remember that open source developers come and go and the more you
speak and go public about your product the more developers come, the
more you go shy and silent about your product the more developers go
elsewhere. I feel our platform is stable and robust enough to justify
a beta cycle (I'm not talking about a stable shiny 2.0 here).
Florent.
Matt Wilson
>
> TurboGears 2 is somewhat uneque in the modern web framework space in
> that it attempts to provide solutions for the archetectual problems
> that limited sites like Pownce, Twitter, and TG1 sites, that I've
> worked on in the past.
traffic issues that hit pownce and twitter.
Mark Ramm
> traffic issues that hit pownce and twitter.
Well, there are lots of issues, and without being super-connected to
either Twitter or Pownce, one of the things that seems to have
happened to both early on is that it was difficult for their platform
of choice to connect to multiple databases and handle horizontal
partitioning.
Beyond that, it was hard for them to manage how many DB hits each page
produced since the ORM's in their platform didn't make it easy to
group sets of db changed together and submit them all at once. Nor
did they have the flexibility that SQLAlchemy provides in grouping
which data will be returned by a request of a particular mapped
object, both because SA provides fine-grained control of what will be
eager-loaded and what should be lazily loaded, and because SA as a
Data Mapper implementation allows objects to map to data from several
tables at once.
Of course both Pownce and Twitter eventually got to the point where
they were using hand-coded SQL and multiple databases for lots of
things, and were still having database scalability issues. And
there's no magic that the framework can do to fix that. But
SQLAlchemy continues to shine as a toolkit even when you're not using
the ORM.
Iain Duncan
>
> > I'm very interested to hear about how TG2 will avoid the scaling and
> > traffic issues that hit pownce and twitter.
>
> Well, there are lots of issues, and without being super-connected to
> either Twitter or Pownce, one of the things that seems to have
> happened to both early on is that it was difficult for their platform
> of choice to connect to multiple databases and handle horizontal
> partitioning.
>
> Beyond that, it was hard for them to manage how many DB hits each page
> produced since the ORM's in their platform didn't make it easy to
> group sets of db changed together and submit them all at once. Nor
> did they have the flexibility that SQLAlchemy provides in grouping
> which data will be returned by a request of a particular mapped
> object, both because SA provides fine-grained control of what will be
> eager-loaded and what should be lazily loaded, and because SA as a
> Data Mapper implementation allows objects to map to data from several
> tables at once.
You know, a detailed tutorial/article on the above would probably be
very good TG2 publicity, as long as you can do so without looking like
you're using Twitter/Pownce as scapegoats.
Iain
Christoph Zwerschke
> I feel that my impressions of learning TG 2 are getting stale. I'm
> going to share some random notes with you (and everybody else) before
> it's to late... :) Sorry for long email.
Thanks for writing this up. So it seems we will need a "everything a TG2
user needs to know about WSGI" article as well ;-) I hope I can find
some time to have a look at TG2 soon, and contribute something like that
or otherwise improve the TG2 docs.
-- Chris
Chris Miles
On 11/12/2008, at 1:47 AM, Mark Ramm wrote:
>
>> I'm very interested to hear about how TG2 will avoid the scaling and
>> traffic issues that hit pownce and twitter.
>
> Well, there are lots of issues, and without being super-connected to
> either Twitter or Pownce, one of the things that seems to have
> happened to both early on is that it was difficult for their platform
> of choice to connect to multiple databases and handle horizontal
> partitioning.
Various levels of caching are also important for scaling high traffic
sites.
Does TG2 offer any inbuilt object and/or template caching mechanism
(using memcached or similar)? Or does it rely on Pylons/Beaker for
caching?
While learning some Django recently I was pleased to see that it
offers caching support out of the box. Pylons offers caching with
Beaker. I assume Beaker is also the recommended caching solution for
TG2, but would like clarification.
Cheers,
Chris Miles
Mark Ramm
> TG2, but would like clarification.
Yes, beaker is the built in caching mechanism of TG2. Beaker supports
memcached, and lots of other back-ends. It also doesn't suffer from
the so-called dog-pile effect i the same way as some other
web-framework's built in caching mechanisms do, because it's just
plain awesome.
--Mark Ramm
Chris Miles
That's good. I've decided to learn standard Pylons before looking at
TG2 in detail. I assume a lot of Pylons knowledge will make working
with TG2 much easier.
For those that haven't already found it, James Gardner's Pylons book
is available to read free online and has been invaluable for my Pylons
learning. http://pylonsbook.com/
Cheers,
Chris Miles
Michael Brickenstein
However, it is a little bit the other way around.
I have now two webapps running TG2 and didn't use any Pylons before:
TG2 is good jump into Pylons. It has a good quickstart template
and chooses reasonable defaults.
Setting some components as defaults also means, that the documentation
can
be more concrete: showing how to use problems with Genshi, SA,
repoze.what in this combination.
Of course, once you are more experienced, it is usually no problem to
abstract from that description.
So, I recommend you, just to start your next project with TG2 :-).
Michael
Sanjiv Singh
background of tg1 and with no background of pylons behind me and I
found that I could use tg2 to a large extent without problems.
Fortunately when I had started on TG1 about 2 years back, I had
started using tg1 along with SA as the ORM. Although a lots of TG
goodies available with SO were not supported on SA at that time, I
made the choice for SA as the devs had made their intentions of
eventually migrating to SA very clear. So that was indeed a big plus
for starting with TG2.
But apart from that I would like to give full credits to Mark (and
others) for making the TG2 controller api almost an exact replica of
TG1. A bunch of wonderful new technologies have been employed in TG2
while keeping the api very similar. From what I gather, Gustavo,
Florent, et al have made even the auth and auth api similar to that of
tg1.
I have worked with toscawidgets over the last one year and found it to
be very similar to TG widgets. Yes, it had lacked some docs, but now
the docs are quite decent.
So while the knowledge of pylons is a definite plus towards fully
understanding the framework, TG2 could be used even without knowing
pylons.
Another thing that I would like to mention here is that all the
support and documentation provided on TG1 by ChrisA, Florent and
Others has and will play a key role in overall success of TG2. Two
things are worth mentioning here
* Much of the TG1 wiki docs were used as starting point for TG2 docs
* The support provided on TG1 has helped and will help TG1 users not
to move away from TG and to stick to the framework and eventually move
on to TG2
I agree with the suggestions of better marketing and an appealing
template for TG2 as they help attract users. But I have another
suggestion here. Can we have a quick 2nd edition of the TG book which
includes WSGI concepts, TG2 api and TW, while people can keep working
on a final good TG2 book in the long term. New users almost always
look whether books are available. If not they just tend to move away.
Finally, kudos to the entire TG team for this wonderful development
and community experience :)
Regards
Sanjiv
Jorge Vargas
>
>
> On 11/12/2008, at 4:36 PM, Mark Ramm wrote:
>
>>> I assume Beaker is also the recommended caching solution for
>>> TG2, but would like clarification.
>>
>> Yes, beaker is the built in caching mechanism of TG2. Beaker supports
>> memcached, and lots of other back-ends. It also doesn't suffer from
>> the so-called dog-pile effect i the same way as some other
>> web-framework's built in caching mechanisms do, because it's just
>> plain awesome.
>
> That's good. I've decided to learn standard Pylons before looking at
> TG2 in detail. I assume a lot of Pylons knowledge will make working
> with TG2 much easier.
>
and you will learn a lot. From someone that comes from TG1 or django,
pylons is like giving you a 10000 pieces puzzle with no picture of the
image and a lot of ocean and sky tiles. So you have to expend a lot of
time reading about the components and understanding how things are
done, and ones your finally done with all those blue tiles you have no
energy to get started with the ship. And this is exactly the kind of
thing TG2 is here for. You start right there at the ship and if you
don't want to expend countless hours on the sky and sea, you don't
have to, but if some part of it is important you can dive in there.
Florent Aide
>
> On Wed, Dec 10, 2008 at 11:44 PM, Chris Miles <miles...@gmail.com> wrote:
>>
>>
>> On 11/12/2008, at 4:36 PM, Mark Ramm wrote:
>>
>>>> I assume Beaker is also the recommended caching solution for
>>>> TG2, but would like clarification.
>>>
>>> Yes, beaker is the built in caching mechanism of TG2. Beaker supports
>>> memcached, and lots of other back-ends. It also doesn't suffer from
>>> the so-called dog-pile effect i the same way as some other
>>> web-framework's built in caching mechanisms do, because it's just
>>> plain awesome.
>>
>> That's good. I've decided to learn standard Pylons before looking at
>> TG2 in detail. I assume a lot of Pylons knowledge will make working
>> with TG2 much easier.
>>
> From the experience of someone that did that, You will be disappointed
> and you will learn a lot. From someone that comes from TG1 or django,
> pylons is like giving you a 10000 pieces puzzle with no picture of the
> image and a lot of ocean and sky tiles. So you have to expend a lot of
> time reading about the components and understanding how things are
> done, and ones your finally done with all those blue tiles you have no
> energy to get started with the ship. And this is exactly the kind of
> thing TG2 is here for. You start right there at the ship and if you
> don't want to expend countless hours on the sky and sea, you don't
> have to, but if some part of it is important you can dive in there.
>
Jorge,
I like the metaphore. This is the differenciating tagline I had been
searching for some time now: "With tg2.0 begin by the ship not by the
sky!". Joking :)
You're quite right, it is interesting to note that TG2.0 is a good
framework in the original sense of the word, that will help you work
with pylons. And as you noted it is really easy to just do something
the pylons way if you think tg is not doing this or that part as you
would like it to be done.
Florent.
Iain Duncan
>
> On Wed, Dec 10, 2008 at 11:44 PM, Chris Miles <miles...@gmail.com> wrote:
> >
> >
> > On 11/12/2008, at 4:36 PM, Mark Ramm wrote:
> >
> >>> I assume Beaker is also the recommended caching solution for
> >>> TG2, but would like clarification.
> >>
> >> Yes, beaker is the built in caching mechanism of TG2. Beaker supports
> >> memcached, and lots of other back-ends. It also doesn't suffer from
> >> the so-called dog-pile effect i the same way as some other
> >> web-framework's built in caching mechanisms do, because it's just
> >> plain awesome.
> >
> > That's good. I've decided to learn standard Pylons before looking at
> > TG2 in detail. I assume a lot of Pylons knowledge will make working
> > with TG2 much easier.
> >
> >From the experience of someone that did that, You will be disappointed
> and you will learn a lot. From someone that comes from TG1 or django,
> pylons is like giving you a 10000 pieces puzzle with no picture of the
> image and a lot of ocean and sky tiles. So you have to expend a lot of
> time reading about the components and understanding how things are
> done, and ones your finally done with all those blue tiles you have no
> energy to get started with the ship. And this is exactly the kind of
> thing TG2 is here for. You start right there at the ship and if you
> don't want to expend countless hours on the sky and sea, you don't
> have to, but if some part of it is important you can dive in there.
OMG, that was hilarious Jorge. What a perfect metaphor. ;-)
Iain
Jorge Vargas
That's interesting as it just came out but given two people took the
time to thank me I guess it's rather good :) I should blog about it or
maybe write some inspiration documents based on the idea, I'll keep
that in mind