Wow, there's been a lot of great discussion on the subject and saturday's IRC meeting turned out to be quite interesting and productive as well. I'd love to take time and talk to every single point, and will actually try to do that more this week, but I thought it would be smart to give a quick higher level update on my current activity and thoughts regarding the whole pyramid/merger thing.
I wasn't clear enough in saying that long term the merger would create two packages as part of the same project, with a single coherent strategy, and unified leadership. One package (pyramid) will fill the base-microframework role, and one (name needed) will be adding on a strong full stack approach with high quality, documented defaults. Over time we'll be exploring abstraction layers in the bottom level that will allow for greater flexibility in the top layer. For example we've been talking about an storage abstraction layer that sessions, caching, and other "framework" pieces can use in place of choosing a specific technology (rdbms tables, key value stores, document databases, LDAP, etc). I'm personally at the point where I'll be spending quite a bit of my open source free time on figuring out how that all is going to work with Ben, Chris, and whoever wants to join us. But, as BDFL I'm not yet making any announcements about the future of TurboGears -- other than the fact that TG 2.1 will be released as planned, and that we will continue to support applications built with it. I'll also be working to create a structure to wrap up this discussion in the next week or two, and make an official roadmap announcement. --Mark Ramm On Thu, Oct 28, 2010 at 9:33 PM, Mark Ramm <[email protected]> wrote: > 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 > -- 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" 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?hl=en.
