Randell's Blog » Python

UnacceptableVersionError: django 1.1 was requested, but 1.2.1.final.0 is already in use

Randell — Mon, 02 Aug 2010 02:00:01 +0000

The Django version I have in my machine is 1.2.1, while one of my apps running on Google App Engine utilizes use_library to use Django 1.1. Apparently, Django versions later than 1.1 is not included in the Google App Engine SDK. So everytime I try to access my app on my dev machine, I get this error:

UnacceptableVersionError: django 1.1 was requested, but 1.2.1.final.0 is already in use

I can probably downgrade the version of Django in my machine, but that would mean all my other apps will have to use the downgraded Django version as well. And I don’t want that, since I want to use the latest version whenever possible. So one possible solution is to use virtualenv for my Google App Engine app. Virtualenv allows the creation of isolated Python environment, which is exactly what I need.

First, we need to install virtualenv. In Fedora, we can install virtualenv by executing the following command as root:

yum install python-virtualenv

Next, we use virtualenv to create an environment that has its own installation directories, that doesn’t share libraries with other virtualenv environments. We can even choose to not use other globally installed libraries. To do that, execute the following command:

virtualenv --no-site-packages ENV

ENV here is the directory of our new environment. This also creates ENV/lib/python2.6/site-packages on Python 2.6, where any libraries that will be installed will go. This also creates ENV/bin/python, which is a Python interpreter that uses this environment. Anytime this interpreter is used, the libraries in this environment will be used. The command also installs Setuptools for the environment, and if ENV/bin/easy_install is used the packages will be installed into the environment.

The --no-packages option during the build causes the environment to not inherit any packages from /usr/lib/python2.6/site-packages. This is useful if we don’t want to depend on the packages there or simply want more isolation from the global system.

Next, we’ll use pip to install the necessary packages in our virtualenv environment. Of course, we need to have pip installed in our system first. In Fedora, we can install pip by executing the following command as root:

yum install python-pip

And then installed the Django version we need into the environment:

pip install -E ENV Django==1.1

To use our new environment, we need to activate it with the following command:

source ENV/bin/activate

Copy the Google App Engine SDK to our new environment and then run our Google App Engine app from that environment like

~/ENV/google_appengine/dev_appserver.py ~/path/to/app

You can follow the same steps to create isolated environments for each of your Python projects.

How to find Django version

Randell — Thu, 29 Jul 2010 17:12:52 +0000

There are cases when you would want to know the version of Django that is being used in your Python installation. To do that, go to your Python console and execute the following commands:

>>> import django
>>> django.VERSION

In my machine, it showed the following:

(1, 2, 1, 'final', 0)

UnacceptableVersionError: django 1.1 was requested, but 1.2.1.final.0 is already in use

Using GAE Testbed with GAEUnit: Testing that email was sent

Randell — Sun, 04 Apr 2010 19:07:26 +0000

In my quest for testing if emails are being sent by my app engine app, I came across GAE Testbed. GAE Testbed

… is a set of base test cases to make it simple to test the more complicated pieces of AppEngine’s framework (such as sending E-mail messages, the datastore, Memcache, etc.)

Since I’m already using GAEUnit as the unit testing framework for my app, I wanted to use GAE Testbed alongside GAEUnit so I only had to call one command (http://localhost:8080/test) to execute all my tests. The documentation from the GAE Testbed home page is written to make it work alongside NoseGAE, so I decided to write one for GAEUnit.

Add GAEUnit to your app:

Download the zipped archive of GAEUnit from its Google Code project hosting page.
Extract the archive.
From the folder extracted from the archive, copy gaeunit.py to your app’s root folder.
Add the following 2 lines to your app.yaml, directly below the line that says handlers::
```
- url: /test.*
  script: gaeunit.py
```
(Optional) From the folder extracted from the archive, there’s a folder named sample_app and inside it is the modified version of the webtest module. Copy the webtest module (the entire folder containing debugapp.py and __init__.py) to the root of your app.

Add GAE Testbed to GAEUnit:

Download the GAE Testbed tar gzipped archive from its Google Code project hosting page.
Extract the archive.
Inside the extracted archive is the gaetestbed module (it’s the folder named “gaetestbed”). Copy the module to the root of your app.
Create a file inside the test folder of the root of your app. For the sake of this example, let’s name it test_mailer.py.

Using the example from the GAE Testbed Google Code project hosting page, add the following lines to test_mailer.py:

import unittest
from gaetestbed import MailTestCase
 
class MyTestCase(MailTestCase, unittest.TestCase):
    def test_email_sent(self):
        send_email_to('test@example.org') # Some method that sends e-mail...
        self.assertEmailSent(to='test@example.org')
        self.assertEqual(len(self.get_sent_messages()), 1)

Start your server and go to http://localhost:8080/test. You should notice that (an additional) 1/1 test was ran from http://localhost:8080/test.

* Many thanks to John Geewax for creating GAE Testbed.

Thoughts and notes on unit testing

Install setuptools in Fedora 12

Randell — Sun, 04 Apr 2010 11:37:07 +0000

From the Python Package Index page, setuptools allows you to

Download, build, install, upgrade, and uninstall Python packages — easily!

The PEAK Development Center, setuptools

… is a collection of enhancements to the Python distutils (for Python 2.3.5 and up on most platforms; 64-bit platforms require a minimum of Python 2.4) that allow you to more easily build and distribute Python packages, especially ones that have dependencies on other packages.

To install setuptools in Fedora 12, run the following command as root:

yum install python-setuptools python-setuptools-devel

Convert CHM to PDF in (Fedora) Linux

Randell — Fri, 02 Apr 2010 18:47:24 +0000

I’ve been looking for a way to print CHM files in (Fedora) Linux, since my CHM file viewer, chmsee, doesn’t have a print option (and probably all other CHM file viewers as well). Searching for CHM to PDF converters in Fedora led me to chm2pdf.

chm2pdf has a couple of requirements:

chmlib
pychm
htmldoc

To install the necessary packages, execute this command in your terminal as root:

yum install chmlib python-chm htmldoc

To install chm2pdf:

Download the archive from it’s Google Code project hosting page.
Extract the archive
As root, type
```
python setup.py install
```
from the directory extracted from the archive

I got the following message after running the last command:

running install
running build
running build_scripts
creating build
creating build/scripts-2.6
copying and adjusting chm2pdf -&gt; build/scripts-2.6
changing mode of build/scripts-2.6/chm2pdf from 644 to 755
running install_scripts
copying build/scripts-2.6/chm2pdf -&gt; /usr/bin
changing mode of /usr/bin/chm2pdf to 755
running install_egg_info
Writing /usr/lib/python2.6/site-packages/chm2pdf-0.9-py2.6.egg-info

I tested the installation with the following command and it produced the PDF file:

chm2pdf --webpage somefile.chm

Thoughts and notes on unit testing

Randell — Wed, 31 Mar 2010 22:25:00 +0000

I’m not a fan of unit testing. As a matter of fact, I have never written any unit tests in my career. Well, I almost did for one of my previous projects that was growing huge, but the client was more interested in seeing the functional requirements met over the non-functional ones (probably because they don’t see progress in it). The project manager could’ve convinced the client that the project needed unit tests, but that’s another topic.

So now I’m facing a project that’s growing beyond what I expected, primarily because I wanted to add features only as the need arises. And as the project grows, I’m encountering circumstances where I already need to refactor a lot, which risks breaking the code. I can test the whole project everytime I refactor the source but I’m too lazy to test everything over and over so I decided to add unit tests to the project.

In search for a unit testing framework that’s applicable for the project, I found out about GAEUnit.

GAEUnit is a unit test framework that helps to automate testing of your Google App Engine application. With a single configuration change (it can be completed within 30 seconds), your unit tests can be run in the real GAE app server environment using a web browser.

I was able to setup GAEUnit after getting over a bit of misconfiguration (the handler for gaeunit.py was supposed to be placed on top of the other handlers in app.yaml and I don’t know why) and used the modified ‘webtest’ module that came with the zipped archive.

So I was set to write my unit tests. Then I realized that I didn’t know which parts of my code needed urgent unit testing except for one, which is to check whether the mailer is working without actually sending an email. Which pieces of my code needed unit tests? I also didn’t want to write too many unit tests. I started to wonder how much unit tests other developers are including in their projects. How do I write tests for functions that needed parameters that are valid and should come from the database? Should I query for valid values within unit tests? Should I write unit tests for those queries that are only used for the unit tests? Should I write unit tests for my unit tests? Or perhaps I can write a program that automatically writes the unit tests that I need?

I found several good points from an article by Tim Burns, Effective Unit Testing, which answers most of my questions:

The crucial issue in constructing a unit test is scope. If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions.
If the scope is too broad, then there is a high chance that not every component of the new code will get tested. The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy.
Start with a feature that is described in the requirements document and work down until a method doesn’t need a unit test. That way, tests are grouped according to major feature and should include as many unit tests that deal with the feature in question as are necessary.
If the code is simple enough that the developer can just look at it and verify its correctness then it is simple enough to not require a unit test. The developer should know when this is the case.
If error handling is performed in a method, then that method can break. Generally, any method that can break is a good candidate for having a unit test, because it may break at some time, and then the unit test will be there to help you fix it.
The programmer should know that their unit testing is complete when the unit tests cover at the very least the functional requirements of all the code. The careful programmer will know that their unit testing is complete when they have verified that their unit tests cover every cluster of objects that form their application.

I’m still looking for good articles on unit testing. Feel free to post your tips and resources.

Install IDLE on Fedora 11

Randell — Thu, 17 Sep 2009 15:02:50 +0000

IDLE is the Python IDE built with the tkinter GUI toolkit.

IDLE has the following features:

coded in 100% pure Python, using the tkinter GUI toolkit

cross-platform: works on Windows and Unix

multi-window text editor with multiple undo, Python colorizing and many other features, e.g. smart indent and call tips

Python shell window (a.k.a. interactive interpreter)

debugger (not complete, but you can set breakpoints, view and step)

To install IDLE on Fedora, simply type the following in your terminal as root:

yum install python-tools

python-tools is the Python package that includes several development tools that are used to build python programs.

After installation, you can now run IDLE from your terminal by entering idle, which should launch a window similar to this:

Screenshot IDLE

web2py Enterprise Web Framework

Randell — Wed, 20 May 2009 01:44:24 +0000

web2py Enterprise Web Framework is a

Free and open source full-stack enterprise framework for agile development of fast, secure and portable database-driven web-based applications. Written and programmable in Python.

web2py follows a Model View Controller design like Rails (Ruby) and CodeIgniter (PHP). Another good thing about web2py is that it can run on the Google App Engine, which I’ve been wanting to use.

web2py doesn’t need to be installed. Just download web2py download page. Click the one that says source code for all platforms. Unzip the file. Change your location to the extracted folder. Then type this in your terminal:

python2.5 web2py.py

You should see the web2py server dialog (see screenshot below).

Screenshot web2py server

You may then enter a one-time administrator password. Clicking the start server button should open your default browser set to the administrator interface (see screenshot below).

Screenshot web2py welcome

web2py also already contains the Python interpreter, web-server and database, but you may customize it to use a different web-server or database.

What is web2py?

Try it online!