As some may have noticed in the tweetsphere (or whatever the catchy term is for that), a Pylons + repoze.bfg framework merger is under way. Some will be shocked, sad, excited, etc. at this move. We wanted to have a good amount of 'support' under the new combined effort which was the main reason there was a lapse in the official announcement. I believe there is now a rather good base of documentation support to help people understand the new combined efforts.
If you're in a rush, and want to jump to bullet points, we've put up a FAQ in the hopes of answering the most obvious questions people will have: http://docs.pylonshq.com/#faq For those curious about the why, I think Chris McDonough's personal perspective perfectly sums up my own thoughts and reasons, included in his announcement to the repoze.bfg mail list. I have included it here: <repoze.bfg announce> Over the last few months, I've been collaborating pretty meaningfully with Ben Bangert, the lead developer of the Pylons (http://pylonshq.com) web framework. This collaboration started because Ben and I have "competing" web frameworks, both written in Python. Our repoze.bfg and Ben's Pylons share almost exactly the same scope. They are both "lightweight" web frameworks. They use similar models for mapping URLs to code. They appeal to roughly the same sort of people. In the meantime, it's clear that there is a limited amount of oxygen in the Python web framework world: only the frameworks which are clear winners will prosper and survive long-term. No potential developer has the time to evaluate 20 separate web frameworks, it just takes too long. Even if they did, to an impartial evaluator, it would be extremely difficult to make a choice between two frameworks as similar as Pylons and repoze.bfg. Ben and I, as well as other folks including Paul Everitt, Mark Ramm, and Chris Rossi met in Las Vegas a few weeks ago to talk about merging Pylons and repoze.bfg. To everyone's surprise, consensus was pretty easy: not only should it be done, it should be done swiftly. We agreed to collapse the crowded Python web framework world a bit in order for there to be slightly more oxygen for everyone to breathe in there. Thus, BFG has now become Pyramid (http://docs.pylonshq.com/pyramid/dev/), and is now part of the Pylons Project. "The Pylons Project" is the project name for a collection of related technologies. Pyramid is the first "new" package which is part of the Pylons Project. Other packages to the collection will be added over time, likely including higher-level components such as applications and other frameworks which rely on a particular persistence mechanism (Pyramid does not). The first release of Pyramid 1.0a1 was made today to PyPI. See http://docs.pylonshq.com/pyramid/dev/narr/install.html for install instructions. Personally, I couldn't be happier about this. I'm proud of the work we've done so far, and I'm extremely optimistic about the future of Pyramid and the Pylons Project. repoze.bfg 1.3 (made November 1, 2010) will be its last major release. Minor updates will be made for critical bug fixes (and so there may be a 1.3.1, 1.3.2, etc), but new feature development will take place in Pyramid. Unless forked, repoze.bfg won't see a 1.4 release. While Pyramid is technically backwards incompatible with repoze.bfg, you won't have to do much to use your existing repoze.bfg applications on Pyramid. There's automation which will change most of your import statements and ZCML declarations. See http://docs.pylonshq.com/pyramid/dev/tutorials/bfg/index.html . The Repoze project will continue to exist. Plenty of Repoze software exists that has nothing to do with repoze.bfg. The Pylons 1.0 web framework, Ben tells me, will be shifted into legacy status once Pyramid has a non-alpha release. </repoze.bfg announce> So for those wondering, will there be a Pylons 2.0? No, not in the sense that the pylons package will hit 2.0. Unfortunately due to reasons I've outlined here: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base Worried about your Pylons 1.0 projects? Don't be! The pylons package isn't going anywhere, and will continue to receive bug fixes and security fixes. I completely understand that some projects using Pylons might be so large a transition to pyramid isn't in the picture, for many of these projects, even shifting to Pylons 1.0 from 0.9.7 wasn't feasible. At the moment, the only reasonable way to transition for those interested is to run your existing pylons application inside pyramid. This is not a problem thanks to the use of WSGI in hooking things up, the existing pylons app can be 'mounted' inside the pyramid app. At that point, you can then transition controllers to the equivalent functionality in pyramid (view handlers). In the future, I would not rule out a Pylons 1.1 if some developers were interested in building a more graceful transition path as well. But for early adopters, there is no shortage of documentation available now, more so than is available for various Pylons 1.0 features in many cases. I really look forward to the large increase in the core developer base this brings to the new Pylons Project, and the ability to expand our scope to start building higher level and more useful tools. Cheers, Ben Bangert -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
