TurboGears joins the Pylons Project
compoundthinking.com
compoundthinking.com
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.
- No clear visual distinction between links to glossary terms and links to further documentation. I like the glossary, but always ended up there without wanting to.
- I did find the tutorials, no issue there. (Only that the paster templates are a bit awkwardly named, but that's not a doc issue.)
- Especially the former BFG stuff, I'm thinking specifically about traversal, is explained in a way that probably makes a ton of sense to Zopeheads, but, at the time anyway, read more like a PhD thesis than like documentation.
- Again not strictly a documentation issue, but the fact that you can configure and use Pyramid in a ton of different ways means there's no straight path from getting started to actually getting something up and running, even with the tutorials. Not being opinionated about anything simply makes it very difficult to write good, forceful docs.
Traversal explaining: we're working on it (really). The docs have been rearranged and massaged a good bit, and they're being futher (professionally) edited now.
Flexibility: the best I can do about that without betraying the goals of the project is http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyra... . I'm also working on a cookbook here: https://github.com/Pylons/pyramid_cookbook which should provide the tl;dr'ers with a way to perform common tasks without needing to read didactic explanations.
The responsiveness of Chris and Ben to actually fixing this kind of thing is amazing, and one of the major reasons we thought teaming up with them would be a good idea.
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.
Reminds me of this blogpost from a while back: http://www.hindsightlabs.com/blog/2010/03/15/jinja2-and-djan...
"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)"
There is a lot that can be said for consolidation. And a lot to be said for the team working on pyramid now, so I'm excited in spite of your skepticism.
Pylons really hadn't had anything other than bugfixes in quite some time, and had some problems with stacked object proxies which would have required a fairly substantial rewrite. Whether you consider Pylons dead or just simply finished is a matter of semantics. I still think Pylons is an extremely capable platform and I don't think you should be afraid to touch it. There is still plenty of mindshare around for Pylons.
However, it bears saying that, so far, no alpha release of Pyramid has been bw incompat with the last in any way. As a result, I wouldn't be scared off much by "alpha" in its version designator, at least as an evaluator. The code in Pyramid has existed for almost 2 years now. Every release has 100% statement coverage via unit tests. An alpha of Pyramid is arguably much more stable than many "final" releases of other web frameworks.
Thanks again though. Looking forward to trying out Pyramid
want something bigger that provides a "full stack"? Django
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.
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.
Ian Bicking made some interesting remarks about BFG back in 2008: http://blog.ianbicking.org/2008/11/06/where-next-for-plone-d...
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.
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.
Spend some time reading the pyramid docs - it it totally agnostic for template engines, authentication/authorization, http session implementation, etc. very pluggable.
I will say though, that at this point 1.0alpha8, a noob will probably get frustrated, but someone who has worked with pylons / repoze / sqlalchemy can connect the dots.
Also, with every alpha release, you can also see the changes to the documentation, which is looking more like django docs (i.e. good)
Django fills a certain niche and if it matches your problem, it is a no brainer. If you need a more flexible web framework, look at pyramid.