* So, I got the news that Pylons2 was going to be built on repoze.bfg, 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: http://www.web-core.org/Home 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 -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
