
TurboGears joins the PylonsProject - admp
http://groups.google.com/group/turbogears-announce/browse_thread/thread/a6ef71ebea4ebcb0?hl=en
======
logic
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.)

------
joshklein
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?

~~~
driax
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.

------
cookiecaper
See <http://news.ycombinator.com/item?id=2045789> for more active discussion,
and this article with headings/better organization.

