
TurboGears joins the Pylons Project - vimes656
http://compoundthinking.com/blog/index.php/2010/12/28/turbogears-joins-the-pylons-project/
======
stdbrouw
The simple fact is that the larger Python community never really cared for
repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces
feels more like a last, somewhat desparate move to garner some attention for
projects that never reached critical mass. I don't think it'll change much of
anything.

I used to do development in Pylons and I've tried my hand at Pyramid, and
there's simply nothing to get excited about. Even the documentation for
Pyramid, which at first seems beautifully comprehensive and one of the
system's strong points, turns out to be an interlinking mess lacking clear
explanations of even the very basics of the system.

True enough, like Pylons before it, Pyramid is anything but opinionated, which
probably makes it a good base platform for the TurboGears devs, but how much
will it matter when people will just shrug their shoulders after looking at
the landing page, and proceed to download Django or Flask/Werkzeug or, heck,
Ruby on Rails?

Anyway, regardless of my scepticism, building new stuff and starting new
projects is always fun, so hopefully the Pylons project devs enjoy the
process.

~~~
storborg
I've been steeped in Pylons for several years now. I agree that Pylons has
nothing to get excited about. However, (and this is the important part) it
provided really straightforward glue to integrate a few other things that are
definitely worth getting excited about: SQLAlchemy, Mako/Jinja, Routes,
Beaker, and Paste.

Pylons' past philosophy always seemed to be "we'll take the best-in-breed of
python web software and put it together in an elegant way." Sadly, they seem
to have abandoned that philosophy for the sake of protecting the precious nest
eggs of massive full-stack framework developers.

While the new changes to Pylons certainly don't prevent you from using the
aforementioned exceptional-quality components, the smushing-together of
projects while trying to retain legacy compatibility seems to have created an
enormous system where there isn't a cohesive or consistent way of doing
things.

No thanks--I think I'll go for WebOb and its lightweight performance.

~~~
stdbrouw
Yep, nothing but love for SQLAlchemy, Jinja, Routes and Beaker. But even given
those components, it's still a hard sell.

Reminds me of this blogpost from a while back:
[http://www.hindsightlabs.com/blog/2010/03/15/jinja2-and-
djan...](http://www.hindsightlabs.com/blog/2010/03/15/jinja2-and-
django-4ever/)

"In the beginning, there was Django, and it was good. But gradually we began
to find its paradigms counterintuitive: we disliked the idea of apps and
considered the built-in template language pretty crippled. More importantly,
we prefer the epically powerful SQLAlchemy to Django’s ORM of Doom, so with
the evidence before us, we switched to Pylons and the haven of
SQLAlchemy/Jinja, only to discover we had switched from a shitty apartment in
Brooklyn to a tent in the desert. No cockroaches, true, but no running water,
either. Who really wants to write a thumbnail library? (Apologies to anyone
who has actually written a thumbnail library)"

------
inovica
Wow, I'm thoroughly confused as to which way to go with Python and web
frameworks now. We do a fair bit of Python work, primarily for back-end
processing (our main work is still in PHP) and we've been trying to move more
to Python. I did a LOAD of research into frameworks and had chosen to go with
Pylons, and then I saw that they were becoming Pyramid. This announcement
obviously means three of them are merging together, but it does make me a bit
nervous. I want to stick with Python, because I love it, but this is all
making my head hurt a little!!! Anyone on here done a load of
research/experimentation already and care to help me make some decisions :) ?

~~~
nek4life
I came to the same conclusion that I wanted to try out Pylons a few weeks ago
right around the same time the repoze.bfg + Pylons merger was announced and
just decided to jump into Pyramid. Recently I've been really impressed with
the flexibility the platform offers allowing me to use all the libraries I had
planned on and to make design decisions that I'm comfortable with. Initially
there was quite a big learning curve as I was unfamiliar with using paste,
what traversal was and if I should use it, best method to configure my app,
etc... Initially this was my only real criticism, the level of indecision this
flexibility instills in a noob, but since then the devs have been actively
working on the docs to make them more beginner friendly and I've gotten some
really great help in the irc channel. I'd say it's definitely worth taking a
look if you were interested in Pylons.

~~~
inovica
Thanks for this. It really helps me to make a decision. All the best

------
gst
In my opinion this weakens both projects. As the ultimate goal seems to be to
build a new framework based on the two, this means that every code you write
today using on of those frameworks will be legacy code soon.

~~~
markramm
Well, by some definition of legacy, that's always true. If we are learning,
using better techniques, and writing better software every day what we wrote
yesterday will be "legacy" code... But I don't think that matters, ther will
be upgrade paths, support for pylons 1 and tg2, and more cooperation and focus
in the development team.

------
markramm
As the current maintainer of TurboGears, I've been thinking a lot about the
python web framework world for the last couple of years, and I have been
thinking for a long time that there's too much splintering of effort.

One choice to solve that problem would be to all join Django, which is widely
used, and has an active developer community. But they have a very strong point
of view about how web applications _should_ be developed, and as a result
django isn't that flexible.

So, in the end what we _need_ is a strong alternative to Django that is
flexible, uses existing libraries to good effect, and just works. By joining
together in the Pylons Project around the Pyramid framework, that's just what
we're aiming to do.

------
sgentle
I'm really excited to hear this, especially after the Pyramid announcement
earlier in the year.

I used to do a lot of Pylons development, and although it was a great
framework that gave you a bunch of ways to do just about anything, I always
had lot of trouble figuring out the _right_ way. Jarring especially
considering the guiding Python principle of "There should be one - and
preferably only one - obvious way to do it".

As a result, Pylons always felt like a big jumble of modules that were all
sort-of right for what you wanted. I'm glad to see some of TG's full-stack
opinionism coming into the fold. I hope all this merging will lead to
something with the strengths of both projects, like the Rails+Merb merge.

------
simonw
Can anyone expand upon the benefits of repoze.bfg?

~~~
stdbrouw
repoze.bfg used to cater mainly to people from the Zope/Plone-world — less
cruft than Zope 2, easier to understand than Zope 3, but the same underlying
ideas and mechanisms: object traversal for URL mapping, ZCML for
configuration, an aspect-oriented vibe etc.

Ian Bicking made some interesting remarks about BFG back in 2008:
[http://blog.ianbicking.org/2008/11/06/where-next-for-
plone-d...](http://blog.ianbicking.org/2008/11/06/where-next-for-plone-
development/)

------
forgotAgain
Sorry to hear about TurboGears. When I first found it I was very excited to
use it. I think they lost a lot of momentum and community trust with the
changes made going from version 1 to version 2. I know after that I felt I
could not use them because I had no way of knowing if version 3 would be
something completely done over again.

------
logic
For cross-referencing, this was also submitted here:
<http://news.ycombinator.com/item?id=2045684>

------
twymer
I was hoping the Pylons blog would have a post about this as well. It's hard
to tell what this means for Pylons going forward.

------
dillon
I personally think it's a great move. The combination of 2 great frameworks to
make something better.

------
cookiecaper
A bit unsettling for me. I use Pylons on several projects, though I haven't
kept up with Pylons news. I really like Pylons because it was to me the best
representation of the ideal framework out there; it was flexible and easy to
plug in your own stuff, it was not haughty or insistent that you do things a
certain way, it did not rewrite Python's whole standard library as many other
frameworks practically rewrite the standard libraries of their constituent
languages; it just stayed out of my way and let me do things the way I wanted
while still providing me the infrastructure to get something published to the
web pretty quickly.

This blog post seems to indicate that Pylons is going more in the direction of
most frameworks with its talk of "full stack" and choosing defaults. Is Pylons
going to become a reimplementation of Django? It's a little weird. I don't
know why Pylons thinks this is better as a single project.

~~~
cd34
I think you're missing what they are doing.

Pyramid is repoze.bfg with some of the good things from Pylons added in.
Pyramid is much more extensible with hooks. TurboGears will still be a full-
stack, Pyramid + their choices for form library, templating, etc. Pyramid is
still very light and makes very few assumptions.

I think it is better since you've brought together three frameworks and that
collective mindshare is going to collaborate rather than compete.

