About the article: this harks back to the Rails/Merb merger stuff in 2008. At the end of the day, I suspect this will only be a good thing; less division of interest amongst developers, and the network effect of having both groups of developers looking at each other's code.
Mind you, I say that as a Django user, so this doesn't really directly impact me. ;)
(Meta: am I the only one unbelievably irritated that people logged in with Apps accounts (without a standard Google account as primary) can't even browse Google Groups without logging out? I've started involuntarily avoiding links to Google Groups because of it, which is a shame.)
I'm trying to understand the stack coming at it from a newbie's point of view. What I'm getting is that Pyramid is the new version of repoze/pylons, and is a lightweight, bare bones framework that gives you plenty of flexibility, whereas whatever the new Turbogears turns out to be will end up being a full-stack framework built on top of Pyramid. Is this correct? Can someone please elaborate?
Pyramid is actually pretty much a fork of repoze.bfg with some minor changes that allow Pylons developers easier porting. Essentially repoze.bfg were newer than Pylons (and therefor learned a lot). It incorporated more flexiblity while being simpler in design. This flexibility also means that a lot of what TurboGears 2 implemented ontop of Pylons isn't needed anymore, Pyramid allows you to use idioms common to both Pylons and TurboGears 2.
Additional Pylons were designed as a lot of WSGI middlewares pulled together. Pyramid is not (so much). The repoze.bfg developer so that Pylons developers had already settled on a common configuration of core middleware, and thus made many of the common middlewares required and therefore more tightly integrated.
So while Pylons were very much a meta-framework, Pyramid is not as much.
I'm unsure about what Turbogears developer exactly wants to do, but there simply isn't as much need for a monolithic framework ontop of Pyramid since it itself is somewhat monolithic and flexible enough to allow extension through libraries. Instead what probably will happen is that a lot of all the extra libraries already built as part of Turbogears 2 will be reworked to work as libaries for Pyramid (not on top of it). (but all of the is conjecture)
Note. I follow the mail-list much don't really participate in the development of any of these projects.
Mind you, I say that as a Django user, so this doesn't really directly impact me. ;)
(Meta: am I the only one unbelievably irritated that people logged in with Apps accounts (without a standard Google account as primary) can't even browse Google Groups without logging out? I've started involuntarily avoiding links to Google Groups because of it, which is a shame.)