I like pylons and I cant understand why everyone is trying to scare off everyone else by calling it “glue”, “a hackers framework”, “it doesnt give you anything, allows you to choose everything”
People would almost think it is the Lisp of frameworks (which it is).
Pylons comes with “batteries included”. Its default setup with Mako, SqlAlchemy, Routes is quite good and I would say a Ruby-on-Rails for Pythoners.
And like RoR, you can fire up “paster shell” to get a nice console. But my best part - how you can set “import pdb;pdb.set_trace()” to start a debug session in a console.
I can wrap my fingers around pylons very nicely - and I like the fact that I can “hack” it if I ever wanted to.
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.
Comments
I like pylons and I cant understand why everyone is trying to scare off everyone else by calling it “glue”, “a hackers framework”, “it doesnt give you anything, allows you to choose everything”
People would almost think it is the Lisp of frameworks (which it is).
Pylons comes with “batteries included”. Its default setup with Mako, SqlAlchemy, Routes is quite good and I would say a Ruby-on-Rails for Pythoners.
And like RoR, you can fire up “paster shell” to get a nice console. But my best part - how you can set “import pdb;pdb.set_trace()” to start a debug session in a console.
I can wrap my fingers around pylons very nicely - and I like the fact that I can “hack” it if I ever wanted to.
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.