Hello Mark, >From a former TG2 user (not because I switched to anything else, but because I don't do Web stuff anymore), the big annoyance has been the lack of polish, which manifests itself in three areas: - software quality - documentation - release management / packaging
The latter two being, in my humble (!) opinion, a disaster. So whatever you choose to do should make it a priority to improve massively on those points. (Just my 3 cents) Regards Antoine. Le jeudi 28 octobre 2010 à 21:33 -0400, Mark Ramm a écrit : > 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" 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.
