Who are the core TurboGears developers?
Nyenyec N
Excuse me for the slightly off topic question.
A few months ago I picked TurboGears over Django for number of
subjective reasons. Part of it was that the website seemed to be
nicer, there was a shiny^H^H^H^H convincing screencast and the mailing
list seemed to be more active (based on number of subscribers).
Since then however, my impression is that Django is growing faster
than TurboGears based on the number of subscribers to their mailing
list and I wonder if that is because they have more people who are
working on and in the framework full time.
So I was wondering how many TG developers are there who develop
applications in TurboGears in their day jobs?
I really hope that the upcoming TG book to which I very much look
forward to and the ongoing effort to clean up the documentation will
put back TG in the lead. :)
Thanks,
nyenyec
iain duncan
> than TurboGears based on the number of subscribers to their mailing
> list and I wonder if that is because they have more people who are
> working on and in the framework full time.
I would not put much stock in mail list subscribers as indicative of
what you should use, that is more a result of marketing and initial
first impression. By that same token we should all go back to PHP, the
community is massive and their docs are amazing. Easy to learn does not
necessarily mean powerful. ; )
And you have to keep in mind that Gears is not "one project" so there
exist mailing lists also for SQLObject, SQLAlchemy, Kid, Genshi,
CherryPy, etc. I have now used both enough to appreciate some strengths
and differences of each, which really have nothing to do with how well
marketed the two platforms are.
At root, I would say ( as does the Django lead, Adrian ) that Gears has
a more unixy approach, whilst Django is more like a mac. Of course
Adrian and I differ on which of those is cooler ( and I own a mac
too!) ; ) Below are my personal opinions, to be taken with much salt.
Results of Django being an all-in-one package that came from an
initially closed source application:
- docs are currently better organized
- code base is more uniform and cohesive, more tightly integrated
- initial impression of a new user is going to be better
- easier to get up and running
- more narrowly focused to the initial problem field, in this case a CMS
aimed for high volume relatively low complexity sites where
non-developers need a good admin, but that admin can be very generic
- simple text based templating language, great for non coders and
situations where templating is mostly a presentation *design* issue
- one mailing list, one dev list, one core dev community ( this has a
lot of pros and cons, I believe the cons are bigger, YMMV )
Results of gears being more modular and following the unix style of
"lots of small tools integrated":
- IMHO a more flexible, cleaner, modular architecture
- much less group think, therefore much more critical analysis of
architecture decisions and future directions, at the current expense of
dev speed
- much better integration with third party options ( sqlalchemy, other
template engines, mochikit )
- harder to use template language that is better for coders doing DOM
manipulation
- harder to learn, more scattered docs, more difficult to get going as
there are more components to wrap your head around
- appropriate for a much broader problem set, especially for complex
applications that require a lot of customization. Customizing the Django
admin is not fun, I tell you! And once you get past what most people
want to do most of the time, the django docs stop looking so hot.
- a more open approach to open source development, which I believe to be
a better long term approach even if it is not as fast moving currently.
I think the gears approach will attract a larger dev base in the long
run.
As someone who will be doing a lot of work with these tools, I'll
continue learning both, but I will almost certainly do any complex
application development in Gears. on the other hand, if a friend told me
they needed to a basic CMS with an admin intergface for a client on a
cheap budget and they had to learn the framework fast, I'd tell them to
learn Django ( and then look at gears later). I believe the gears payoff
to be a bit further down the learning curve, again a lot like linux.
Once you learn grep and awk and bash and regular expressions, gui's
start to look like pretty lame ways to get things done. ;)
My two cents as a recent convert. I'm always interested in hearing
critical analysis of both sides. ( Though you won't see much of that on
the Django list, frankly. )
Iain
Bob Ippolito
It's probably also worth mentioning Pylons, which pretty much does the
same thing as TurboGears, but does a better job at being "unixy". I've
been playing with both Pylons and TurboGears lately, and I definitely
have to say that Pylons really gives TG a run for its money.
The big pros are:
1. WSGI, not CherryPy. Easy to plug in or write middleware, easier to
get "to the metal".
2. Routes, not CherryPy. Far better control over URL dispatch.
3. Their customized EvalException integration is *awesome*. Debugging
is terribly easy, and it's easy on the eyes (unlike raw EvalException,
which is ugly and less usable).
4. A "public" directory that covers the whole webroot rather than "/static".
5. Easier to add "stdvars", just stick them in project.lib.helpers
The things that TurboGears does better, in my experience:
1. Unicode. Pylons doesn't really touch it, but it's easy to code
something up that deals with decoding the request params (or
cut+paste). I'm sure they'll fix this soon though.
2. DB integration. Pylons doesn't really have any, but it's really
easy to write your own. New users would get bitten here though.
3. The toolbox. I never got much use out of it because I'm using
SQLAlchemy and no ORM (ORM is no good for massive reporting stuff with
lots of joins). I imagine many users really take advantage of the
toolbox though.
4. Documentation. There's definitely more of it, especially with the
book now. I can't say that I was exceptionally happy with either TG's
or Pylon's docs, but TG's seems more complete and mature.
Even after having to write my own unicode and db support stuff, I
ended up removing more code than I added when porting a project from
TG to Pylons. I would still recommend TurboGears to new users though,
because Pylons definitely still has areas where you end up rolling
your own solutions to common problems. For advanced users that's not
such a big deal, and the pros may very well outweigh the cons.
-bob
Jorge Godoy
> So I was wondering how many TG developers are there who develop applications
> in TurboGears in their day jobs?
I do. All of my current ongoing development projects are based on
TurboGears.
> I really hope that the upcoming TG book to which I very much look forward to
> and the ongoing effort to clean up the documentation will put back TG in the
> lead. :)
The book is already there. :-) It was released last weekend. ;-)
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> Since then however, my impression is that Django is growing faster
> than TurboGears based on the number of subscribers to their mailing
> list and I wonder if that is because they have more people who are
> working on and in the framework full time.
One thing that I forgot commenting on my message: what languages (and lists,
of course) have you considered? There are Japanese, Portuguese, Spanish,
Chinese, etc. lists for TurboGears. Not everybody is comfortable or wants to
speak English.
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
> The book is already there. :-) It was released last weekend. ;-)
http://www.blueskyonmars.com/2006/11/14/turbogears-book-is-out-
photographic-evidence-here/
iain duncan
But backordered out here. =(
( Well good for the authors, it means pre-sales exceeded indigos
expectations! )
Kevin Horn
Kevin H
Simon Wittber
> So I was wondering how many TG developers are there who develop
> applications in TurboGears in their day jobs?
I'm paid a salary to develop TurboGears applications, if that is what
you are asking. TurboGears application programming consumes ~70% of my
day.
-Sw.
Stuart Clarke
in Turbogears. It's not exactly my day job, but if I perform well, it
will become my day job.
It's my first foray into web development, however. So we'll see how
that goes :-)
Stuart
--
Stuart Clarke <sjcl...@tpg.com.au>
Sanjay
> applications in TurboGears in their day jobs?
We are developing an application using Turbogears (and this is our day
job). One of the major motivating factor over Django was TG's built-in
support for SQLAlchemy. It might be true that nothing restricted us to
use SQLAlchemy or MochiKit with Django or Pylons, but being new to web
development and python, we wanted to avoid gluing works as far as
possible, and rest on TG.
sanjay & ranjan
iain duncan
> > So I was wondering how many TG developers are there who develop
> > applications in TurboGears in their day jobs?
I have only just switched from Django to Gears for a few on the go
projects. It's my harf a day job, but only because I only want to work
part time. In the last six months it could have been my full job had I
wanted to work that much, but I'm self employed as a musician and
juggler in the corporate and festival entertainment world when I'm not
coding.
Iain
Arnar Birgisson
> So I was wondering how many TG developers are there who develop
> applications in TurboGears in their day jobs?
I develop web applications for my day job 8-12 hours each day. The
applications are various in-house information systems for a commercial
printer based in Iceland with operations in the US, Poland and
Romania.
Since I started to use TurboGears some 6 months ago I have developed 2
fairly large and one small projects with it. However I'm thinking that
for my next project I'll just use CherryPy directly, TG is a bit too
high level for my needs.
Arnar
percious
-percious
iain duncan
> Since I started to use TurboGears some 6 months ago I have developed 2
> fairly large and one small projects with it. However I'm thinking that
> for my next project I'll just use CherryPy directly, TG is a bit too
> high level for my needs.
Though a little off topic, I'm interested in knowing at what point gears
feels too high level, and which components make that the case. Would it
be the ORM or do you find you need more architectural flexibility?
Thanks
Iain
Karl Guertin
> Though a little off topic, I'm interested in knowing at what point gears
> feels too high level, and which components make that the case. Would it
> be the ORM or do you find you need more architectural flexibility?
I'll indulge this offtopic response. I don't know how long you've been
around, but until a little over a year ago, there were dozens and
dozens of web frameworks for Python. They're still out there (and more
are added all the time Cloubrid, web.py, etc), but TG, Django, and
Pylons cover enough ground that they're good enough for most people.
The thing about the full stack frameworks is that they make a lot of
decisions for you. Many experienced Python developers don't like
CherryPy, particularly the dispatch. Others don't like Kid. If you're
not making use of widgets, error handling, identity, or the toolbox,
then there's no reason you can't roll your own framework with Paste.
This is basically what Pylons and CleverHarold are.
The goal for 1.1 (as I understand it) is to make TG a wsgi-based
framework and to break up the TG pieces into self-contained units so
that they can be reused in other wsgi-based frameworks.
iain duncan
> The thing about the full stack frameworks is that they make a lot of
> decisions for you. Many experienced Python developers don't like
> CherryPy, particularly the dispatch. Others don't like Kid. If you're
> not making use of widgets, error handling, identity, or the toolbox,
> then there's no reason you can't roll your own framework with Paste.
> This is basically what Pylons and CleverHarold are.
>
> The goal for 1.1 (as I understand it) is to make TG a wsgi-based
> framework and to break up the TG pieces into self-contained units so
> that they can be reused in other wsgi-based frameworks.
That sounds very cool. Does that mean one would be able to unplug
CherryPy from the middle and use Pylons or Rhubarb Tart if they are more
appropriate for the task at hand?
I realize this must make docs a lot harder, but it makes for a more
attractive advanced tool kit in my books.
Iain
Karl Guertin
> CherryPy from the middle and use Pylons or Rhubarb Tart if they are more
> appropriate for the task at hand?
I believe so.
> I realize this must make docs a lot harder, but it makes for a more
> attractive advanced tool kit in my books.
I'm not worried about the docs. They'll be written for the official
way of doing things with pointers on how to do things differently,
probably about like the SQLAlchemy doc today, maybe a bit better.
Sylvain Hellegouarch
> The thing about the full stack frameworks is that they make a lot of
> decisions for you. Many experienced Python developers don't like
> CherryPy, particularly the dispatch.
If TG moves to CherryPy 3 it won't be a problem anymore considering
CherryPy comes in built-in with:
- its own dispatcher
- an HTTP method dispatcher
- a Routes dispatcher
And adding dispatcher is really easy.
Moreover CherryPy 3 is fully WSGI compliant now (both as a server and as
an application).
- Sylvain
Mark Ramm
> CherryPy comes in built-in with:
>
> - its own dispatcher
> - an HTTP method dispatcher
> - a Routes dispatcher
>
> And adding dispatcher is really easy.
>
> Moreover CherryPy 3 is fully WSGI compliant now (both as a server and as
> an application).
Yes, we definitely have to find some body with a little bit of time to
work on this. I don't think the CherryPy 3 migration will be hard,
and it will be well worth the trouble!
--Mark
Arnar Birgisson
Sorry for the late response. Others have mention most of the points
that lead to my statement. The fact of the matter is, as I have said
here before:
* I use SQLAlchemy, so so model designer, catwalk and all the
crud-magic widgets are of no use.
* I use routes, in effect I short circuit the normal dispatching.
* I dislike the explicit turbogears.database.session, for my last
project I kept the identity related model in sqlalchemy and used a
completely seperate model for my business logic.
* I needed more from the identity framework so I had to write my own
identity controller.
* I don't use widgets, they mostly just don't apply to my projects so far.
* I don't like the std. @expose decorator in turbogears since it wraps
the function making it unusable from regular Python code, this was
partially solved with writing my own dispatch logic.
CherryPy 3 is looking very good imo, currently I'm leaning more
towards that rather than Pylons. I also like the asynchronous
methodology of Twisted, esp. if one needs long-running requests as in
Comet.
Arnar