Pylons 0.9 released
Posted by ben Tue, 01 Aug 2006 17:18:55 GMT
Last week during OSCON 2006, I was able to get a release of Pylons out. This version had some big internal changes, no longer using custom Myghty resolvers. We now use a very straight-forward WSGI interface to setup the application and the middleware. It’s easier to customize as a result, and the call-cycle is very understandable.
A bonus of our emphasis on using the WSGI specification and having a flexible architecture, has been that we’ve been able to maintain a very high degree of backwards compatibility despite such a large internal change-up. Many Pylons 0.8 applications run with absolutely zero changes under Pylons 0.9. Now that we’re using a clean and powerful API for our internal components, we can begin to add more new features without any backward compatibility issues.
Additional cool features in 0.9:
- Swap the default templating language to your choice of TurboGears compatible template engine plug-ins
- Controllers are called with the WSGI interface, enabling powerful application re-use
- Custom version of Buffet that can cache templates rendered with any supported template engine
- Mapping system now supports HTTP method restrictions for REST-ful web services
- Interactive debugger can be used to examine AJAX triggered exceptions
We’re still adding more great features, and working towards a very solid and robust 1.0 release soon. The existing feature set of Pylons is rather large as well, since many of the projects Pylons leverages have been making great strides (SQLAlchemy, Paste, Routes, etc.).
About Pylons
Pylons combines the very best ideas from the worlds of Ruby, Python and Perl, providing a structured but extremely flexible Python web framework. Python concepts are utilized as often as possible to increase your knowledge re-use (Knowing Python makes Pylons easy), in addition to fully leveraging the WSGI protocol for maximum code re-use.
Cool. I’ve read over some of the documentation and code, and Pylons is looking/sounding pretty good. Some day I’ll carve out some time to give it a spin.
Incidentally, I noticed some of your changes to the BuffetMyghty plugin (full Myghty options, fragment support), and I’m going to roll them into the variant that I publish in the Cheeseshop.
I’ve given most if not all of the Python frameworks a spin, and so far I like Pylons the most. Why? I like it because it feels the most buffet-like (not the project, the pick-what-you-want kind).
How tightly coupled to Myghty is Pylons now? I’m working with 0.9.3 and I’ve found that with some very minor changes I can remove the requirement for Myghty entirely – I’m using Genshi for templating and 0.9.3 only appears to use Myghty for templating and nothing else.
For many people deployement in a corporate network or even a cautious one minimization of dependencies is very important, sometimes a concern which can make or break the decision to use a product. Being able to trim the requrements list of Pylons down by removing Myghty (easily done, it would appear), FormEncode (even more easily done), nose (same), and others (Beaker if neither sessions nor caching are used) can be a big deal.
With regards to Beaker, it appears as though Beaker is used for the default session and caching management. I would have preferred to find in the tutorial a message like “if you want to enable sessions, here is how you do it – the default session management is provided by Beaker” and so on.
To me, the whole promise of WSGI is somewhat diminished by the thought that to use Pylons one must download and install several other software packages that aren’t strictly necessary – the overwhelming majority of people in corporate environments use packaging like RPM and do not rely on setuptools. I’ve found that pitching ideas to my boss goes much easier when I don’t have to say that I have to package up a half-dozen bits of software we haven’t used before.