1.0.1 Status Update
Alberto
I've decided to delay The release of TG 1.0.1 until Monday. I've just
comitted 3 patches this afternoon and, being Friday (you all know you
should never buy a car which was manufactured on a Friday, right? ;)
I've decided not to rush 1.0.1 and leave a couple of days until they
"settle down". Apart from that, 2 releases in one day (ToscaWidgets
first alpha is now available!) is just too much for me... ;)
So... 1.0 SVN users: please update your checkouts and report back if
anything has mysteriously stopped working.
I've also created a 1.0.2 milestone due in 2 weeks. All new ticket
should target that milestone, not 1.0.1.
Pending tickets in 1.0.1 which a provide a valid fix or a test
(hopefully both) will be comitted along the weekend. #1245 just needs a
little mockup and consolidation into a single diff to get it.
Tickets that can't be solved/comitted for 1.0.1 will move to 1.0.2.
The most important ticket right now in 1.0.1 is #1241. It doesn't need
someone who really knows TG's internals, just a little bit of English
skills and some free time. So if anyone is looking forward to
contribute and is waiting for a low hanging fruit, #1241 is the most
delicious one right now... :)
Again, Thanks to everyone who is helping to make this release possible!
:)
Alberto
Christopher Arndt
> The most important ticket right now in 1.0.1 is #1241. It doesn't need
> someone who really knows TG's internals, just a little bit of English
> skills and some free time. So if anyone is looking forward to
> contribute and is waiting for a low hanging fruit, #1241 is the most
> delicious one right now... :)
I can do that. I'll update branches/1.0/CHANGELOG.txt, right?
Should I include fixes for test cases in the changelog?
Chris
Alberto Valverde
On Jan 19, 2007, at 8:28 PM, Christopher Arndt wrote:
>
> Alberto schrieb:
>> The most important ticket right now in 1.0.1 is #1241. It doesn't
>> need
>> someone who really knows TG's internals, just a little bit of English
>> skills and some free time. So if anyone is looking forward to
>> contribute and is waiting for a low hanging fruit, #1241 is the most
>> delicious one right now... :)
>
> I can do that. I'll update branches/1.0/CHANGELOG.txt, right?
Yep. The trunk CHANGELOG would also need an update but don't worry
much about it, I can take care of copy&pasting from the 1.0 changelog
later...
> Should I include fixes for test cases in the changelog?
Not really, just a high-level description of the changes. Something
like:
"fixed a bug in X which made browser Y crash"
Take a look at previous versions to see the format.
Oh, and a list people who've contributed to the release would also be
nice... but I can also take care of making it if you don't have the
time.
Thanks! :)
Alberto
Christopher Arndt
> Oh, and a list people who've contributed to the release would also be
> nice...
Yeah, I'm already doing this.
Chris
Felix Schwarz
I would like to add that some testing for MySQL/SQLObject users would be nice in
order to verify my fix for #1235.
If you use MySQLdb 1.0 with a MySQL 4.1 database (RHEL 4), you have TIMESTAMP
fields in your tables and are using autogenerated SQLObject class, the new
configuration option "turbogears.enable_mysql41_timestamp_workaround" should
help you.
All others should test that the new code has no side effects when enabling the
option above (defaults to False).
fs
Randall
same time TurboGears started gathering steam, several other frameworks
either started up or came to my attention in what looked like a Python
web framework revolution. I think it's been about a year since and it
would be nice to see where these frameworks stand today. A
comprehensive list is here: http://wiki.python.org/moin/WebFrameworks.
Looks like Django and Pylons (two that I've evaluated) are moving
along and nearing 1.0 status. Anyone have enough experience with these
other frameworks to say how they compare to TurboGears today?
Karl Guertin
> It's nice to see TurboGears finally pass the 1.0 milestone. About the
> same time TurboGears started gathering steam, several other frameworks
> either started up or came to my attention in what looked like a Python
> web framework revolution.
It pretty much was.
> Looks like Django and Pylons (two that I've evaluated) are moving
> along and nearing 1.0 status. Anyone have enough experience with these
> other frameworks to say how they compare to TurboGears today?
I use Django when I can do a project using only admin. I prefer
SQLAlchemy, Genshi, and TG's returning dictionaries to the Django
equivalents, so I don't use it otherwise. Pylons is recommended if you
feel that TurboGears makes too many component choices you disagree
with. Django has better docs than TG, TG has better docs than Pylons
(last I checked).
Bob Ippolito
Pylons and TurboGears are practically the same thing if you're using
SQLAlchemy, since none of the TG admin tools really do you any good in
that case.
The internals to Pylons make more sense to me because it's based on
lighter weight stuff than CherryPy (paste and WSGI). It's also a
breeze to debug with EvalException. Pylons pretty much covers all of
the functionality I was looking for, in a more straightforward manner
than TG... but the TG community has a lot more momentum. It would
certainly be interesting to see more cooperation between the two, e.g.
if the TG admin tools were WSGI based then it could be interchangeable
just like the Buffet template plugins that both frameworks use now.
-bob
Joshua J. Kugler
> Pylons is recommended if you feel that TurboGears makes too many component
> choices you disagree with.
How does Pylons compare with some of the "convenience" features of TurboGears
such as Catwalk and Model Designer?
j
--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE
PO Box 80086 -- Fairbanks, AK 99708 -- Ph: 907-456-5581 Fax: 907-456-3111
Bob Ippolito
>
> On Saturday 20 January 2007 14:10, Karl Guertin wrote:
> > Pylons is recommended if you feel that TurboGears makes too many component
> > choices you disagree with.
>
> How does Pylons compare with some of the "convenience" features of TurboGears
> such as Catwalk and Model Designer?
>
Doesn't have them. Neither does TG if you're using SQLAlchemy :)
It does have a really good implementation of EvalException for
debugging, which is a LOT more useful than the model design stuff in
my experience.
-bob
Karl Guertin
> Pylons and TurboGears are practically the same thing if you're using
> SQLAlchemy, since none of the TG admin tools really do you any good in
> that case.
I know, but I'm comfortable with TG.
> The internals to Pylons make more sense to me because it's based on
> lighter weight stuff than CherryPy (paste and WSGI). It's also a
> breeze to debug with EvalException.
There's an option to enable EvalException debugging in TG by setting
tg.fancy_exception = True, but the CSS was messed up last I checked.
> if the TG admin tools were WSGI based then it could be interchangeable
> just like the Buffet template plugins that both frameworks use now.
I don't know how closely you've been following the planning, but the
goal is to get TG split back up into reusable components. Alberto has
started this with ToscaWidgets. I know a number of people expressed
interest in developing the FastData module into an independent
project. I'm interested in doing an admin-type project, but the docs
for 1.0 need to be finished first.
Paul Johnston
I took a look at Django when deciding what framework to use. Compared to
TG, at a first look Django feels more polished - the documentation in
particular is excellent. It's auto admin system is great, particularly
because it is configurable. The problem I found with Django was that if
you wanted to do something that doesn't quite fit its approach, you're
back to doing things the long-hand way. It doesn't have the whole
widgets/validators system that TG has, although they are working on this
with "newforms". The Django ORM is nice for simple operations, but
doesn't have the power of SQLObject (e.g. there is no SQLBuilder
equivalent). The Django controller is more flexible, being based on
regular expressions, but I find CherryPy's syntax is preferable for my
work. So, all things considered, I decided to use TG and my decision is
reinforced the more I learn.
Many people (including Guido) have commented that it would be great to
combine the efforts of the projects, to produce one "hyper framework".
I'd say in the short term, merging TG and Pylons is a more likely
prospect, but perhaps Django could be brought closer. I believe
ToscaWidgets already contains pretty much all the functionality of the
Django "widgets" in newforms. If Django started using TW, we would have
the beginnings of a meeting of minds. Fastdata2 could then be modelled
after (or even replaced by) Django's auto-admin system. All the project
already seem to be moving towards SQLAlchemy as the ORM. The controller
is a harder one to merge - the regex/expose mechanisms will just suit
different people. But perhaps the controller will become as pluggable as
the template engine currently is. If all this happened, Django would
effectively just be TG, using a particular choice of controller and
templating engine.
Frameworks are becoming more like distributions every day...
Paul
Bob Ippolito
> > Pylons and TurboGears are practically the same thing if you're using
> > SQLAlchemy, since none of the TG admin tools really do you any good in
> > that case.
>
> I know, but I'm comfortable with TG.
I was too... but I've never liked anything about CherryPy. Pylons
gives me all of the good things about TG (that worked with SQLAlchemy
anyway) and gets rid of the parts I didn't like. I am looking forward
to seeing what happens with the next major revision of TG, but as-is I
don't find TG compelling anymore now.
> > The internals to Pylons make more sense to me because it's based on
> > lighter weight stuff than CherryPy (paste and WSGI). It's also a
> > breeze to debug with EvalException.
>
> There's an option to enable EvalException debugging in TG by setting
> tg.fancy_exception = True, but the CSS was messed up last I checked.
Yeah, there's a big difference between what Pylons has and what TG
has. Pylons has some little additions to EvalException that make it
quite aesthetically pleasing and easy to use. I didn't have nearly the
same experience w/ the EvalException in TG.
> > if the TG admin tools were WSGI based then it could be interchangeable
> > just like the Buffet template plugins that both frameworks use now.
>
> I don't know how closely you've been following the planning, but the
> goal is to get TG split back up into reusable components. Alberto has
> started this with ToscaWidgets. I know a number of people expressed
> interest in developing the FastData module into an independent
> project. I'm interested in doing an admin-type project, but the docs
> for 1.0 need to be finished first.
I try and keep up with the list, but I haven't been paying very close
attention. Sounds like the right direction, though.
-bob
Jorge Vargas
>
> It's auto admin system is great, particularly
> because it is configurable.
don't like the idea of having the model objects define the strings for
the GUI.
> The problem I found with Django was that if
> you wanted to do something that doesn't quite fit its approach, you're
> back to doing things the long-hand way.
*cough* Ruby on Rails *cough*
> It doesn't have the whole
> widgets/validators system that TG has, although they are working on this
> with "newforms".
I think TW will be better for this.
> The Django controller is more flexible, being based on
> regular expressions, but I find CherryPy's syntax is preferable for my
> work. So, all things considered, I decided to use TG and my decision is
> reinforced the more I learn.
you can get something similar in TG with a little magic
http://routes.groovie.org/ and
http://docs.cherrypy.org/writing-your-own-dispatcher
> Many people (including Guido) have commented that it would be great to
> combine the efforts of the projects, to produce one "hyper framework".
> I'd say in the short term, merging TG and Pylons is a more likely
> prospect, but perhaps Django could be brought closer.
yes I'll like that too many people doing the same thing is a waste of time.
> I believe
> ToscaWidgets already contains pretty much all the functionality of the
> Django "widgets" in newforms. If Django started using TW, we would have
> the beginnings of a meeting of minds. Fastdata2 could then be modelled
> after (or even replaced by) Django's auto-admin system.
maybe when django finish their port to SA if they keep some
abstraction the auto-admin stuff could be ported.
> All the project
> already seem to be moving towards SQLAlchemy as the ORM. The controller
> is a harder one to merge - the regex/expose mechanisms will just suit
> different people.
I for ones don't like it, regex are good for somethings IMO this is
not one of them.
> But perhaps the controller will become as pluggable as
this is one of the things all the WSGI goodness is supposed to solve.
> the template engine currently is. If all this happened, Django would
> effectively just be TG, using a particular choice of controller and
> templating engine.
>
> Frameworks are becoming more like distributions every day...
well I love that :) my biggest problem with ALL frameworks is that
sometimes it's harder to get around it then just doing what you need,
TG is very good at not getting on your way.
Peter Russell
> On 1/20/07, Karl Guertin <gray...@gmail.com> wrote:
> >
> > On 1/20/07, Bob Ippolito <b...@redivi.com> wrote:
> > > Pylons and TurboGears are practically the same thing if you're using
> > > SQLAlchemy, since none of the TG admin tools really do you any good in
> > > that case.
> >
> > I know, but I'm comfortable with TG.
>
> I was too... but I've never liked anything about CherryPy. Pylons
> gives me all of the good things about TG (that worked with SQLAlchemy
> anyway) and gets rid of the parts I didn't like. I am looking forward
> to seeing what happens with the next major revision of TG, but as-is I
> don't find TG compelling anymore now.
I'd be interested in knowing what you dislike about CherryPy, I've been
using it quite a lot recently, and found it to be very transparent, and
well documented - to the point I almost wonder why they felt the need
for a new version!
I'm prejudiced against Paste, partly because I don't really get what it
is, and partly because the parts of Turbogears that seem to give me the
most headaches (SQLObject and Formencode) have websites with the same
templates as the Paste website :-)
>
> > > The internals to Pylons make more sense to me because it's based on
> > > lighter weight stuff than CherryPy (paste and WSGI). It's also a
> > > breeze to debug with EvalException.
> >
> > There's an option to enable EvalException debugging in TG by setting
> > tg.fancy_exception = True, but the CSS was messed up last I checked.
>
> Yeah, there's a big difference between what Pylons has and what TG
> has. Pylons has some little additions to EvalException that make it
> quite aesthetically pleasing and easy to use. I didn't have nearly the
> same experience w/ the EvalException in TG.
You've just led me to discover this in TurboGears. I've been
complaining that interactive debugging of turbogears is too hard for
ages, and I had no idea this existed. Thanks!
--
Peter Russell <peter....@qustom.co.uk>
Qustom
Christopher Arndt
> I'm prejudiced against Paste, partly because I don't really get what it
> is, and partly because the parts of Turbogears that seem to give me the
> most headaches (SQLObject and Formencode) have websites with the same
> templates as the Paste website :-)
Because all these projects were initiated by Ian Bicking. Ian seems to be a
gifted hacker and I really like FormEncode, but, unfortunately, he doesn't seem
to bother much about documentation for beginners or even (e.g. in the case of
Paste) about putting a proper description, in simple words, of what a package
does on the webpage.
Chris
Karl Guertin
> I'd be interested in knowing what you dislike about CherryPy, I've been
> using it quite a lot recently, and found it to be very transparent, and
> well documented - to the point I almost wonder why they felt the need
> for a new version!
CP3 is faster and is WSGIfied!
> I'm prejudiced against Paste, partly because I don't really get what it
> is, and partly because the parts of Turbogears that seem to give me the
> most headaches (SQLObject and Formencode) have websites with the same
> templates as the Paste website :-)
To make a simplifying analogy, WSGI serves the same purpose in web
frameworks as Buffet does in templating. It allows the possibility of
mixing and matching components across different packages. Paste
provides a set of tools for gluing WSGI components together. The
websites use the same templates because the projects were all
started/written by Ian Bicking.
If you took CherryPy 2, exploded it into it's atomic components and
wired them back together with Paste, you'd basically have the pieces
of Pylons that differ from TG. CP3 is similar in concept, but it's not
wired together using Paste. I'm glossing over some details, but that's
the basic idea.
> You've just led me to discover this in TurboGears. I've been
> complaining that interactive debugging of turbogears is too hard for
> ages, and I had no idea this existed. Thanks!
It's turned off by default because it allows remote code evaluation.
Peter Russell
Yeah, I realised that it was all Ian Bicking, I was trying to be
polite :-)
Formencode and SQLObject are both very simple and elegant ideas, but the
implementations seem to be overly complicated and in the case of
SQLObject's support for MySQL somewhat buggy. I get the impression he's
a very smart man who comes up with good ideas which are never quite
perfected.
Peter Russell
> On 1/23/07, Peter Russell <peter....@qustom.co.uk> wrote:
> > I'd be interested in knowing what you dislike about CherryPy, I've been
> > using it quite a lot recently, and found it to be very transparent, and
> > well documented - to the point I almost wonder why they felt the need
> > for a new version!
>
> CP3 is faster and is WSGIfied!
>
> > I'm prejudiced against Paste, partly because I don't really get what it
> > is, and partly because the parts of Turbogears that seem to give me the
> > most headaches (SQLObject and Formencode) have websites with the same
> > templates as the Paste website :-)
>
> To make a simplifying analogy, WSGI serves the same purpose in web
> frameworks as Buffet does in templating. It allows the possibility of
> mixing and matching components across different packages. Paste
> provides a set of tools for gluing WSGI components together. The
> websites use the same templates because the projects were all
> started/written by Ian Bicking.
>
> If you took CherryPy 2, exploded it into it's atomic components and
> wired them back together with Paste, you'd basically have the pieces
> of Pylons that differ from TG. CP3 is similar in concept, but it's not
> wired together using Paste. I'm glossing over some details, but that's
> the basic idea.
And is the end result as good as CherryPy? I was surprised to hear Bob
say he didn't like CherryPy, because I thought it was a good example of
a project that was complete in it's domain, and easy to use and
understand, whilst powerful. It's clearly (to me) very well thought
out. I've been able to do a lot with CherryPy without having to read
the source code (try that with Turbogears widgets, SQLObject or
FormEncode!), and where I have (only ever trying to debug errors I've
made myself) I've found it very transparent, I've looked at one or two
functions without having to internalise whole modules.
There are a lot of bits of a standard TurboGears that I have issues with
(mostly the bits that are being replaced: SQLObject, Kid, Widgets).
CherryPy isn't one of them.
>
> > You've just led me to discover this in TurboGears. I've been
> > complaining that interactive debugging of turbogears is too hard for
> > ages, and I had no idea this existed. Thanks!
>
> It's turned off by default because it allows remote code evaluation.
Yeah, that's understandable. Still it is sweet and a great example of
what WSGI can do for us :-)
Karl Guertin
> And is the end result as good as CherryPy?
I'm not familiar enough with the various packages to make that call.
There was a discussion immediately following the 1.0 announcement
where Robert Brewer (fumanchu, CP project lead) was arguing that CP3's
take on WSGI was better than Paste.
> It's clearly (to me) very well thought
> out. I've been able to do a lot with CherryPy without having to read
> the source code (try that with Turbogears widgets, SQLObject or
> FormEncode!),
I've always been happy with CP, which is why I'm not in a hurry to
move to Pylons. As for the rest, I'll give you widgets and SO, but
I've never had a problem with FormEncode and I do write custom
validators, Schemas, etc.
> There are a lot of bits of a standard TurboGears that I have issues with
> (mostly the bits that are being replaced: SQLObject, Kid, Widgets).
> CherryPy isn't one of them.
Well, from a user perspective Kid and Widgets will mostly be replacing
themselves. SO has worked well for me in the past when I don't have to
deal with legacy databases. I've had serious problems with both SO and
SA on MySQL databases and have been problem free on Postgres and
SQLite, though that may because all the big production DBs I work on
are MySQL.
Mark Ramm
> certainly be interesting to see more cooperation between the two, e.g.
> if the TG admin tools were WSGI based then it could be interchangeable
> just like the Buffet template plugins that both frameworks use now.
This is the direction we are headed, towards decoupling tools from the
core, using more WSGI, releasing separate libraries, and generally
becoming easier for Pylons to steal from. (And hopefully
vice-versa!.
People always ask me when TurboGears and Django are going to merge or
at least start sharing more code -- and I tell them that we're just
too philosophically different so that's a harder than it looks. But
the Pylons folks are just as interested in code re-use, WSGI, and all
of that good stuff. So I would hope, and expect, that we have a lot
of fertile collaboration with Ben and friends in the future.
I'm sure that Alberto would agree, since he seems to be a happy user
of both frameworks. ;)
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Mark Ramm
documentation -- if only because he writes some great code ;)
If the rest of us help out with Documenation of his projects, I'd
rather he keep writing code ;)
I've been wanting to write more about Paste for quite a while, but I
just haven't had time to work on it with all of the other stuff that's
been going on (like the TurboGears book).
But I promise, I'll get to it "Real-Soon-Now."
Karl Guertin
> People always ask me when TurboGears and Django are going to merge or
> at least start sharing more code -- and I tell them that we're just
> too philosophically different so that's a harder than it looks.
You're too diplomatic. The reason is that the Django guys -- who are
far better hackers than I -- NIH everything. I can understand their
reasoning, but that's why code isn't shared.
Mark Ramm
> far better hackers than I -- NIH everything. I can understand their
> reasoning, but that's why code isn't shared.
They want a silo they can control, so they can manage things and
provide the tightest integration possible.
I personally don't agree with that philosophy for a web framework, but
I respect their choice, and I'm sure that it has a lot of benefits.
My main objection is that innovation happens at the edges, beyond the
boundaries of your project/company/group and if you don't recognize
that and stay open to code from "outside" you won't be able to compete
in the long term.
That's the specific philosophical difference which keeps TG and Django
from working together more. And that isn't a problem with the Pylons
folks -- they're very pragmatic about code re-use in the same way that
the TG project leaders have been.
--Mark Ramm