Python Web Framework Series – Pylons: Part 7 Refactoring Deployment and Wrap up
Lets take a look at our existing site and what we can do to clean it up and add some badly needed functionality, however that is beyond the scope of my series. So I’m going to leave some hints for the remaining functionality to get you started.
Refactoring Ideas
###
- Replace default authkit login with custom login. HINT: make a sign-in link on your public page. then redirect to a custom login page that uses authkit. Trying it any other way will make you lose hair.
- Refactor database access into a class or two. This will make the db access more testable and allow you to monkey patch in different behavior later. HINT: If your controllers can avoid having to know anything about SQLAlchemy you’ve done your job.
- Replace return “rsvihla” in the users.py module with actual authkit user. HINT: just access pylons request object: “request.environ.get(“REMOTE_USER”)”
- Create admin ui for users, with roles. HINT: look at Pylons Book for Authkit ideas here.
- Split threads into categories and then give the ability to respond to posts. HINT: just more controllers and views.
- Makes parts of your view visible depending on if a user has certain rights or not. HINT: while this is not what you’ll find in the Pylons Book I highly suggest not have gobs of if/else checks in your views. Make small functions that you can unit test easily which will change what is visible depending on role, then have your views call these. See what I did with my user.py module for a concept.
Deployment
This almost completely depends on your situation with hosting. If you are using something like WebFaction you just have to upload files and follow their directions. I found it trivial to have a production site up and running with them.
Now if you are using your own dedicated server or want to shrink wrap the project I suggest using Python Eggs, this is not pylons specific at all and I’ve built them for a number of other projects. There are some snags you can run into depend on your platform and how portable you want to make this but as long as your dev platform and production platform are the same all you need is “python setup.py bdist_egg” and you should have a egg file in the dist directory which can be installed with easy_install.
Finally, you’ll want to build a production.ini . By and large you can copy your development.ini but you must must make your debug = false or you’ll give people access to your application in all sorts of bad ways. Also, don’t forget to make your secret strings actually secret strings.
Overall Impressions
Things I like:
- Pretty easy to get up and running quickly.
- paster and nose integration is pretty slick.
- being able to functional test response including view is actually nice. Really wish I had this in Monorail as easily.
- Component based to the hilt. If you really don’t like something you can switch it out.
Things I don’t like:
- AuthKit is like all auth frameworks I’ve used, just a lot to make work the way I want.
- Too much violation of dry in the config. AuthKit being the main culprit here, while I may want to change which datasource I use, I’m not sure how helpful it is to have to select “form, cookie” for each ini file I make.
- Explicitly calling the view in my actions. Should have some convention over configuration here.
So I could certainly see using Pylons more once I get my own auth solution worked out, and get my own code flow working I could actually probably get work done more quickly in it than most web frameworks I’ve learned. The majority of the time I wasted learning was dealing with authkit, in fact that took more time than everything else I studied combined.
Thank you for taking the time to get this far with my posts. If you have any specifics parts you want me to dive into more depth and/or suggestions for me on the next series (which will be Pyxer with Google App Engine) let me know.