Month: May 2011

For my Django upgrade project, I see several steps for each of the four applications:

• Review the code and update on my laptop
• Pass to the designer for any changes he needs to make (probably not many related to the Django version change)
• Move the code to the DEV server to test Apache and Oracle compatibility
• Deploy to QA and test the heck out of it.
• Deploy to production and hope nobody notices

The first time I work on the DEV server, there will also be virtualenv things to work out.

Application #1 has gone through the first step. so I’m now starting work on app #2. It’s a little bigger, so this may take a little longer. Keep in mind that this first step is all being done in my spare time.

Work has been pretty crazy, so I haven’t had time to talk with the server admins about virtualenv or Oracle 11g. Hope to get to it soon.

In addition to the Django version upgrades I’m in the middle of, I also am facing a scheduled upgrade of the Oracle version used by my apps. They share an Oracle instance with the enterprise application that runs the business, so these smaller systems upgrade on the big guy’s schedule.

Currently, all run on Oracle 10g, and the DB platform upgrades to 11g in July. Shouldn’t be a big deal, but I don’t have enough experience with the Oracle client running on the web servers, or with the Python interface to Oracle.

This project starts next week.

Looking through the release notes for v1.3, I don’t see any backwards incompatible issues that affect me. As for new features, there is an index that is now used on the session table that I can add, and the much heralded class-based views are now available.

Looking through the deprecation list, I did find a couple of things to check. First, an upcoming change to the url template tag warrants a look through my code, and the eventual removal of the function-based generic views means that I can either fix them now or during the next upgrade.

Hopefully, this will be quick, not only on my first, uncomplicated application, but the more complicated ones I’ve written more recently.

I have the first application upgraded from v1.0 to v1.1 of Django (spending most of my time with the environment, not with code), so I’m ready to move on to v1.2. My quick review of the release notes shows just a couple of things I have to change, and may I’d like to change. (Stay in scope, Dan!)

CSRF protection – requires a tag to be added to every form, plus changes to the middleware settings.
Multiple Database Declaration – allows the use of more than one database. Not a required change now, but since the old code will be deprecated soon enough, I thought I should get the change made while it is fresh in my mind.

There are so many posts on the web covering how to get the Python Imaging Library (PIL) to work on Linux, and they almost all say the same thing: install libjpeg6.2 and then recompile/install PIL.

What most fail to mention is that one apparently needs to also remove the previous PIL install before reinstalling. I don’t know (and don’t care to research it), but I think that the install sees the already compiled code and skips that step. Wonder if there is an option that forces new compiles.

So, find wherever your distribution stores the Python site-packages/dist-packages and remove the PIL directory and PIL.pth file before running install. Just to be thorough (and maybe a little anal retentive), I also removed the unpacked directory of PIL source.

Also, and this is the BIG PIECE OF NEWS to me, for those using Ubuntu 11.04 like me, libjpeg6.2 won’t work. Instead, use libjpeg8. In the Synaptic Package Manager, a quick search for libjpeg will show both versions. Leave libjpeg6.2 alone, but be sure to remove any dev libraries for that version. Then, mark anything that looks remotely connected to libjpeg8 and apply.

Now that your old version of PIL is gone, and the libs are squared away, it is time to install PIL. I used version 1.1.7. Finally, success!

(Well, except that I seem to have not installed the library that enables PNG use. Some other day maybe.)

UPDATE:
To enable PNG support in Ubuntu 11.04, use these commands to find the zlib library BEFORE installing PIL:

$ cd /usr/lib
$ sudo ln -s i386-linux-gnu/libz.so libz.so

ANOTHER UPDATE:
Using version 12.04 of Ubuntu, I also had to create a symbolic link for libjpeg – AFTER following the instructions above and BEFORE installing PIL:

$sudo ln -s i386-linux-gnu/libjpeg.so libjpeg.so

 

My quick review of the 1.1 release notes only found a few things to update to move my v1.0 application up a version.

• Unmanaged Models – will be very helpful with my latest app that uses legacy tables
• Admin URLs – uses include syntax
• Reverse Admin URLs – I’ve already coded this in two apps, but had to comment it

Also, I’m looking at the {% empty %} clause of a {% for %} loop in templates. It will be a lot cleaner than the current method of checking for data in the data source, although I did promise myself not to do any refactoring. We’ll see how that goes.

As the title of this post reveals, I’m a little behind in Django versions on my app server. There are several reasons why:

No virtualenv

My server admins, who are very competent, don’t have experience with virtualenv (that I know of). Without this tool on the server, it is impossible to upgrade one app at a time, or even introduce a new application using a newer version. The app I just deployed on Friday is using 1.0.4.

Other App Work

I’ve been either writing new apps or adding functionality to existing apps pretty much constantly for the past 18 months. No time to freeze features and upgrade.

Other Work

My main job function is as a manager, so I can’t sequester myself inside Eclipse for a month to get things up to date

Besides being vulnerable to bugs that have long since been fixed, I am also unable to use any of the new features that have come out in the past three years. Aggregation functions, CSRF, class based views, and others tempt me with their usefulness, but I can’t take advantage of them.

So, the project to upgrade has started. First step was to review the release notes for the three versions that succeed 1.0 to refresh my self on the changes – especially the backward incompatible ones. I’m not looking to do a lot of refactoring unless the change is required for the app to run under v1.3. That will come later during work on the next release of each app. I have a pretty short list of things to check and update before I even try to run in the latest version of the framework.

I’m currently in step two, which is to begin to modify the first app to run under v1.3. Since I already have virtual environments setup for each app, its no problem to switch things around as I work. Also, I’m adding a new branch in SVN for the 1.3 work in case any maintenance needs come along.

Third step, or more likely concurrently with step two, will be to work with the sysadmins to setup virtualenv on the DEV server. We will isolate each application (there are four) in its own environment and then I can update and test the code for each at my own pace as changes are ready. I think that once they see the benefits of separating the dependencies of each program, they will accept it wholeheartedly.

Lastly, we will setup the virtual environments on the QA and PROD servers and move things forward. My users (and customers) will hopefully not notice as this happens.

Wish me luck!