The perils of accidental version upgrades

Wasting Time “Runs on my machine”
As a developer and engineering manager, this is one problem I see all time.I did it to myself today and wasted more than an hour

All because “install newest version” is the default

Tracking down environment changes and differences is often a big time waste. The code really does “runs on my machine” for one developer and does not work for someone else, even then the followed the same instructions. I’ve seen days wasted on these kinds of issues, often involving both the victim trying to run the new code, and the developer that created the code. Having been on both sides of the problem many times, I still get really annoyed when it happens.

I use a Windows laptop as my main computer. To allow creating code that is more likely to work on Amazon, I am setting up a VirtualBox with XUbuntu.

I set up python the same setup I had done on my Windows computer a few weeks ago. Really, I have my notes. I had already played with Ubuntu enough to know I needed to use python3.

Silly me, I should have expected “it worked last week” would not be good enough. I wanted to have this done yesterday.

In setting up the environment, I used the standard python “pip” command to install the latest version of the various libraries I used.  I was not paying attention to the version, things “should just work” work new versions?  Right?  NO, I was being lazy.

I noticed PyDev is slightly different, but this has not been a problem so far.

Then all of my unit tests failed. Really, they did run yesterday.  This was the first of the dreaded “runs on my machine” problem I’ve had in while, except it was my own two machines!

Following my standard practice, I searched on the error: “RuntimeError: App registry isn’t ready yet”.  I found a great page describing the problem. I verified that old post is still correct by checking the documentation for “Backward incompatibilities” in the actual DJango documentation.

The fix is simple. For my unit tests, I now need to explicitly run the setup() method.

Here is then the full snippet of a unit test my cimis project:

import os
# set location of database for tests
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cimis.tests.settings")

import unittest

# Django 1.7 initialization with backward compatibility
try:
    import django
    if hasattr(django, 'setup'):
        django.setup()
except AttributeError:
    pass

Thanks to Nicolas Kuttler for his help.

Comments are closed.

Powered by WordPress. Designed by Woo Themes