Over dinner tonight a group of us were discussing packaging of Python applications and packages. Many of these discussions happen among developers and users, but you often don't hear about it from the system administration side.

One of the things we brought up was that Python is kind of challenging for System Administrators, particularly in production systems, to handle. This is because Python moves pretty fast. A production-oriented LTS OS release will typically include system packages for an older Python. But developers want to build their programs with a newer version of Python -- usually the newest. This isn't the developers fault, or the system admins, or Python...

Read on for some ideas that were discussed...

System Admins either need to stick to the system provided Python, or they need to package and track updates and test the desired version. But not just Python, because you'll also need to do the same for all the modules, because even if the system provides the right version of a module, it won't be built for, or best case installed in a directory for, the newer Python. So when we do this, we often see 20 to 50 packages that need to be built and tracked for updates.

Doing this right can take a lot of the System Admin's time.

One option that was discussed, which seems promising for further discussion, would be to shift this responsibility to the developers. In other words, treat Python and the required modules as part of the application, instead of as part of the system.

One benefit of this is that the developers are probably then developing with exactly the same bits that production would be using, and the same SVN that the developers are using would also track the applications.

So where does this stop? Do you check in your whole OS? Probably not, because while Linux, say, is fairly fast moving, most developers really don't seem to rely on specific new features that are coming into them, either at the kernel or application levels (except, of course, Python :-).

So we now have Python and modules in SVN, built up and distributed to production. If new versions of the libraries come out, or Python itself, presumably some defect would be entered in the bug-tracker about the issue, and then new versions would be brought in to fix them. Or, customizations could be done and tracked.

This hasn't been thought through very extensively, as I said it was just discussed tonight at dinner. It sounds promising though and may be worth some more thought.
(Post Reply)