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
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
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):
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,
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
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.
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!
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):