A modest proposal for the future of TurboGears
Mark Ramm
and among other things, that got me looking at various options for
our future.
I decided we could:
* Build on top of pylons on top of bfg,
* Build on top of bfg directly
* Take the microframework (which had been being taken by pylons) and
move it back on as a core part of TG.
Jonathan Lacour did a great little experament at the last TG sprint on
where he investigated the last option:
http://github.com/cleverdevil/pecan
Chris Perkins showed me something he and Allice have been working on
which is pretty similar, but more mature:
These approaches help in some ways, they reduce or shift our
dependencies, and provide possible futures. But they would both be
TG3 type events. They'd be much smaller than the tg1 to tg2
transition, but there would still be a number of small
incompatibilities. I'm more than willing to do that kind of thing,
but am a bit hesitant about them if we're not absolutely sure that
this is the right thing to do for our users. So I was also been
seriously thinking about forking Pylons 1 to keep tg2 going long term
on that platform.
Pylons/bfg sprint
As I was thinking all that through, Ben Bangert contacted me to let me
know that there was going to be a bfg/pylons sprint, and I flew out at
the last minute to check it out.
There was a lot of discussion about how bfg and pylons work, a bunch
of discussion about how we can all work together better.
The point I emphasized a bit was that Django is doing a great job of
marketing, and the current situation is something like this:
#1 Python web Framework
---> Django
#2 Python web framework
---> TurboGears or Pylons or repoze.bfg or flask or...
Given the number of choices for the second position, people are
defaulting to Django because they don't know how to choose beyond
that.
All three frameworks have been talking about how to build higher level
abstractions (oauth support, admin tools, a widget system, etc) so
that we can better compete with Django feature for feature.
So, it was proposed by Ben, that we just all go ahead and figure out a
way to do what Rails and Merb did and stop building on top of one
another and find a way to actually merge our three communities.
Merger Talk
The merger discussion boiled down to a couple of questions:
Is there a common core that we can all agree on, and build around?
Are we willing to make the kinds of adjustments and compromises to
actually make this happen?
So, we did a lot of talking, a quite a bit of experimentation, and
more talking, and after a bunch of fits and starts, I think we came to
the conclusion that, if our communities were interested, yes we could
make this happen.
We decided that this experimental package would be created with
several core TG philosophies in mind:
We aim to create a full stack framework that gets you started quickly
We will take advantage of reusable components, and to use the best
tools available
And would use several common turbogears idioms by default:
* expose decorators
* returning a dictionary
* simple controller methods
We also got at least started on support for sqlalchemy, genshi,
turbojson/jsonify, and many other very common turbogears tools.
There's a new experamental package called Pyramid which is the result
of a lot of that talk and experimentation:
http://github.com/Pylons/pyramid
It has support for us to build in object dispatch, already supports
pylons style routes, and a third kind of dispatch which I'm going to
call site-tree traversal, all of which are backwards compatable with
our existing frameworks.
And better than that we created a "legacy" handler that allows you to
mount existing pylons or turbogers (2 for sure, and probably 1)
applications directly inside of a Pyramid app. People can then
migrate bit by bit as the feel the need.
My thoughts on what to do
----------------------------------------
I went in thinking a merger would require giving up too much.
But ultimately I found that the repoze.bfg and pylons folks recognize
the same need to build a strong framework for application code re-use,
and have begun looking at a more full-stack approach on their own.
And given all of our agreement about the best approach, I quickly
changed my mind.
Chris McDonough and Ben are very willing to work with us to achieve
the very goals that TurboGears was founded on. In a real way they
are being assimilated into Kevin's original vision for TurboGears --
just in a new package. If we join with them I think we can and should
take the lead in creating the next generation of high level tools that
will directly compete with the best that the django community has to
offer.
I left the sprint excited about the new blood that this would bring to
the TG developer community And I'm not sure how much we can afford
not to band together to build something awesome. It will require us
all to make some sacrifices, let go of some code that we love, and
embrace new approaches to some of the problems we've been facing.
But in the end, I think we will find that we're working with a much
larger group of talented python web experts to build a framework with
greater potential and greater reach than what we can do on our own.
And perhaps most importantly, it will be an opportunity for us to take
control of a much broader spectrum of our dependencies, so we don't
get left behind by abandoned projects, etc. And that control will
give us a much better ability to document, support, and prove the
value of our component based approach to web development, and in the
end, that's what I care about. Well, that and getting things done,
which I think will be a lot easier with Ben, Chris, and all the other
pylons and BFG developers on board.
No decision has yet been made, and I'm very interested in hearing what
you all think about all of this. Let the fireworks begin! ;)
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog