Pylons & repoze.bfg Merger - or - Where'd Pylons 2.0 go?
Ben Bangert
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
dusans
>
> 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
> 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>
>
Ben Bangert
> Will there be a python 3.x version also?
The lead developer of repoze.bfg, Chris McDonough co-authored this PEP for a WSGI-type Python 3 compat. adapter:
http://www.python.org/dev/peps/pep-0444/
So when that is approved, and has an implementation (which we'll try and help with as well), we absolutely plan on having a Python 3.x version. Having a larger development team now will definitely make it a lot easier.
Cheers,
Ben
Mike Orr
This is some other work by the team that is now giving you Pyramid. A
lot of work has gone into how to adapt WSGI for Pylons 3, whether a
simplified WSGI 2 API is worthwhile, or whether it's time to go beyond
WSGI to a new protocol such as Web3. I'm in the Web3 camp, and am glad
ChrisM has advanced it to a PEP. The Pylons-Turbogears-BFG developers
are actually the majority of WSGI developers (at least those that show
up to the WSGI PyCon sprint), and some of them are ready to just
implement a new protocol rather than waiting for the Web-SIG to reach
a consensus (which it hasn't for two or three years now). (I have
suggested a higher-level WebOb-based protocol.) Of course everything
would still have WSGI adapters, but it would also have adapters for
the new protocol, whose most viable contender at this point is Web3.
--
Mike Orr <slugg...@gmail.com>
Ben Bangert
>> So when that is approved, and has an implementation (which we'll try and help with as well), we absolutely plan on having a Python 3.x version. Having a larger development team now will definitely make it a lot easier.
I'm sorry, I stand/sit corrected. Chris tells me PEP-333 is the current best choice. So I'm all on board for that, if it meets the needs. Chris McDonough mentions it was based on Web3 to an extent.
I'm not really in the know much on that, but suffice it to say, with a larger dev team, this is much easier than before. :)
- Ben
Mike Orr
> On Nov 7, 2010, at 12:53 PM, Mike Orr wrote:
>
>>> So when that is approved, and has an implementation (which we'll try and help with as well), we absolutely plan on having a Python 3.x version. Having a larger development team now will definitely make it a lot easier.
>
> I'm sorry, I stand/sit corrected. Chris tells me PEP-333 is the current best choice. So I'm all on board for that, if it meets the needs. Chris McDonough mentions it was based on Web3 to an extent.
Huh? PEP 333 is the original WSGI spec, which is still at 1.0 and
still has its flaws.
--
Mike Orr <slugg...@gmail.com>
Graham Dumpleton
http://www.python.org/dev/peps/pep-3333/
Mike Orr
<graham.d...@gmail.com> wrote:
> He would have meant 3333. See:
>
> http://www.python.org/dev/peps/pep-3333/
Well, Pyramid is moving away from middleware anyway, and providing
other ways to extend applications (e.g., the event hooks), so maybe
this will be less significant. But I still think WSGI needs to get rid
of 'start_response' and 'close', they make WSGI-compliant interfaces
unnecessarily hard to write and read, and more error prone.
--
Mike Orr <slugg...@gmail.com>
Ben Bangert
> On Sun, Nov 7, 2010 at 2:43 PM, Graham Dumpleton
> <graham.d...@gmail.com> wrote:
>> He would have meant 3333. See:
>>
>> http://www.python.org/dev/peps/pep-3333/
Yup, doh.
> Well, Pyramid is moving away from middleware anyway, and providing
> other ways to extend applications (e.g., the event hooks), so maybe
> this will be less significant. But I still think WSGI needs to get rid
> of 'start_response' and 'close', they make WSGI-compliant interfaces
> unnecessarily hard to write and read, and more error prone.
Right, well at least, middleware is fine, but we're trying to keep it now for things that aren't actually necessary for a Pyramid app to run. Like how a PylonsApp actually required a specific middlware stack to run.
Weak that PEP-3333 still uses the start_response stuff, sigh. At this point, I honestly don't care as long as its "good enough" for us to write WSGI webapps with it under Py3.
Cheers,
Ben