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

  1. 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.
  2. 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.
  3. Replace return “rsvihla” in the module with actual authkit user. HINT: just access pylons request object: “request.environ.get(“REMOTE_USER”)”
  4. Create admin ui for users, with roles. HINT: look at Pylons Book for Authkit ideas here.
  5. Split threads into categories and then give the ability to respond to posts. HINT: just more controllers and views.
  6. 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 module for a concept.


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 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.

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in Authkit, Pylons, Python. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • In regards to AuthKit, looks like you got further with it than I did. I gave up eventually and rolled my own which was not all that difficult for login/logout/register. However, I have since moved on to repoze.what. Good test coverage, and good docs, and pretty extensible You might want to check it out

    Also, I really enjoyed this series. One thing that I’m getting my head wrapped around now is how to use paste to make composite applications. To me at least that seems like it would be a good part 8 if you are up for it. I’m no epxert but I’m beginning to see the potential now.

  • @Tim Thanks for the tip on repoze I’ll gladly take a look at it.

    Glad you enjoyed the series it makes it worthwhile when someone gets something positive out of it.

    Finally, I’ll take a look into a part 8 with composite/templated apps , It didn’t seem to be terribly hard and we’ll see what I can put together.

  • zihotki

    I agree with Tom. Also could you please add some notes about caching of rendered templates and data from db and view model’s data? I’ve experience with Django but I have never looked at Pylons.
    Thanks in advance.

  • zihotki

    And forgot to mention, big thanks for your series about Pylons, I enjoy them!

  • @zihotki Since Pylons is component based I’m not aware of anything specific to the framework for caching. I know that Mako has its own caching support SQLAlchemy does not support internal caching and some people have had luck with Memcache .

    Looks like a pretty big subject for SQLAlchemy and a very small one for Mako, neither really a happy medium for a blog post. I’ll do some research into this later and see what I can find.

    Thanks again for the kind words.

  • Really nice read. I also ended up rolling my own auth system mostly using decorators. I just wrap em around the controller actions specifying necessary access level, it’s kind like AuthKit (if I recall correctly) just a lot less bloat.

    As for caching, take a look at .