Software releases 6: skeletons for easy best practices¶

Tags: python, softwarereleasesseries, buildout, django

This is the last post in my software releases series (at least, the last as I originally planned the series).

In the last 5 articles, you’ve seen a couple of places where there’s some irritating boilerplate. What’s supposed to go into your setup.py? How did you start off with a buildout.cfg again? Oh, don’t forget the CHANGES.txt and a basic README.txt. The solution for that is something I normally call a skeleton. I mentioned skeletons earlier in a Dutch python user group talk on practical project automation.

A skeleton is a basic project structure with a README, a couple of directories, some python files to start off with and whatever else you want to put in there. You give it some parameters (project name, website address, whatever) and it’ll fill in the blanks with those parameters.

Django has a manage.py startapp, but there’s a generic python tool called PasteScript. PasteScript’s documentation almost exclusively talks about running wsgi applications, but it actually can create project skeletons for you. The best way to get started is to look at ZopeSkel, which has a large collection of skeletons. Download it and see what it can do.

There are two core advantages to using skeletons either for yourself or within your community or within your company:

• Boilerplate reduction. Basic files get created and set up for you. Laziness works to your advantage. “Just start the project from a skeleton” gives you something reasonably solid and neat. The alternative is to just start off with a python file and a sub directory and “remember” to add the readme and so later.

• Best practice. Pour your knowledge into a skeleton. Figure out the way you want to set up your projects once and reap the fruits many times over. You’re probably copy-pasting apache config files from one project to the other: why not keep the latest and greatest config file in the skeleton? For me, this is the number one advantage: you’ve got a place to collect your project setup best practice. And having that place to put it means that more best practice gets attracted!

Want to start your own skeleton? What I’d recommend is to start with a ZopeSkel download and to look at their code and how to set it all up. Then start your own. I worked for Zest software and started “zestskel” there. I worked for The Health Agency afterwards and started “thaskel” there. Now I work at Nelen en Schuurmans so I’ve started “nensskel” here :-)

Some examples of what I get when I create a new django site with nensskel (after giving it a project name):

• Basic setup.py with project name filled in. Long description is read from the readme and changelog. Some common dependencies are pre-filled.

• buildout.cfg which sets up django, creates apache config files, contains package-versioning best practice setup, contains some commonly used tools, etc.

• Readme, changelog, todo file. Of course with the project name in there.

• Basic apache config file. In here there’s also the configuration that’s needed for django’s static files. And some caching setup. And the wsgi configuration. And the setup needed for django-compressor.

• A directory with the actual django app (empty models.py, views.py and so). A bit like how django’s manage.py startapp does it, but now with our own defaults.

• Our own defaults? Yes, for instance the boilerplate needed in settings.py for our django-staticfiles css/js setup. You definitively don’t want to type that by hand.

• Pre-created PROJECTNAME/templates/PROJECTNAME, PROJECTNAME/media/PROJECTNAME and PROJECTNAME/fixtures/ directories.

• Ready-made test setup just the way we like it.

So: make it easy to do the right thing. Let laziness work in your favour. Start a skeleton today!