I get the impression Pylons tries to be the "anti-Django" inverting the NIH attitude of Django and trying to be all things to all developers. The end result however is a huge number of dependencies and options that make installation and setup harder than it should be. Turbogears 2, which is based on Pylons, has an even greater number of dependencies - such that I needed to install virtualenv to get going with it.

For example, in order to support a large number of template engines, Pylons uses Buffet, another library which provides a common interface for these engines. Typically, however, you will only use a single template engine in your project and it only needs a few lines of code to set an engine up.

Although I do most of my web development in Django, when I do need more control or something a bit simpler I go with a Werkzeug + SQLAlchemy + Jinja stack (plus WTForms, similar to Django forms but in a standalone package). The code needed to get up and running isn't that much more than Pylons (and paster generates a whole lot of code anyway) and I can count the dependencies on one hand. That makes deployment a lot faster and easier, and it's just as easy to swap out these dependencies as with Pylons.

I love the idea of Pylons, if for nothing other than its inclusion of SqlAlchemy, which I respect hugely.

However, after working on a medium-sized Pylons project for a few months, I found that there was quite a bit of "glue" that I had to implement myself, the type of thing that's typically handled under the hood by other frameworks like Django.

Perhaps it was my own ignorance or drive for simplicity/elegance, but I wound up getting nervous about the lack of these standards, and I got pretty frustrated about constantly rolling my own architectural solutions with little more guidance than comments in bug reports and scattered blog posts.

That's not to bash on Pylons - I think it's incredibly powerful, and in comparison Django (or Rails) feels a little like moving from power tools to a Fisher Price toy. Regardless I think it's the established standards that make these more mainstream frameworks better choices (in a business sense) for banging out working products.

it would be interesting to know what problems you faced. If you could elaborate on the roadblocks you hit - and how other frameworks solved it for you, that would be great.

Looking back, I think I struggled with Pylons' lack of convention (or perhaps flexibility) more than anything else. There seemed to be a lack of consensus (or as I saw it, no established "best" solution) for handling common middleware tasks such as user authentication. It seemed like I was spending more time on application architecture than fleshing out a working system.

This was over a year ago, and I'm sure some things have improved, but looking back into that Pylons Cookbook still gives me the willies.