Chris convinced me at last year’s ConFoo that I should re-join the TurboGears
community, voice my opinions, and try to help out. Unfortunately I no longer
feel comfortable camping here, as my role as direct competitor (aka “The
Enemy™”) gives me a not-so-minor conflict of interest. Additionally, the
pervasive belief in the “not invented here” mentality blinds people to the
reasoning behind some of my decisions and ensures I get very little respect.
There has been some great discussion in the last few days about perceived
issues, future possibilities, re-inventing the wheel, community, and joining
forces. Unfortunately what I’m seeing so far is a repetition of the 1.x → 2.x
migration. A significant problem with “best of breed” is the criteria. Too
often in the past I have seen things jumped on too hastily and three months
later seen the regret.
> One package (pyramid) will fill the base-microframework role
30KLoC in 149 modules a microframework does not make. Especially when it
re-implements template engine adaptors (alacarte), session handling (Beaker),
configuration file parsing (PasteDeploy), thread locals (Paste), has a large
amount of authentication/authorization code to adapt repoze.{who,what} (a
package I recall people saying was a mistake to make required for TG2.0),
object dispatch (crank), regex-based routing (Routes), static file serving
(Paste), etc. The majority of these are modules contained within one package
and thoroughly blended.
All of this needs testing and documentation, all of which would be more useful
as reusable, and more importantly, optional components. Most are already
available as reusable components. From the standpoint of a template engine
developer I have to write adapters for two widget systems, at least one
framework (probably more), and still have my own API to deal with. As a
framework user, if I want to use a templating engine that’s new -I- have to
write the adapters. The duplication of work is horrendous.
It’s one thing to decide that a Django-inspired framework design (everything
and the kitchen sink available with no dependancies) is the way to go, in which
case rigid structure and organization is necessary, another to want a
microframework base, and a third to have a modular best-of-breed framework.
Pyramid seems to me to be none of these, and has quite the intimidating
codebase.
TurboGears 3, or the future project with no name yet, doesn’t need Pyramid from
a technical standpoint. It didn’t need Pylons. WebCore showed that utilizing
the same components as TurboGears (PasteScript, PasteDeploy, Genshi/Mako,
ToscaWidgets, Beaker, SQLAlchemy, etc.) without a parent framework can be
trivially easy, modular, light-weight, and fast. Relying on another ‘base’
framework seems to me to be a repeat of past mistakes, with more pitfalls than
benefits.
I look forward to seeing what the future will bring for all of our projects.
— Alice.
--
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.
