DB2 support for Django 1.1 is now available. I have just released ibm_db_django-0.1.2 and all the above points about packaging, uploading to pypi etc. have been taken care of. For users who are still using Django 1.0.x code line, our adapter is backward compatible. Would love to hear your comments/suggestions for the same.

http://groups.google.com/group/ibm_db/browse_frm/thread/98c2c700412688

Thanks and Regards
Tarun Pasrija

@Kevin
Thanks for your great comments/suggestions. We appreciate them, so please keep them coming. For #1, #2, #3 these will be corrected. For #4, we will be supporting these from PyPI.

For #5 and also answering James, it was sure not the intent to be asking for insertion into Django this way 🙂 (although Jacob’s view is public @ http://simonwillison.net/2009/Feb/18/db2/#c43517 ) We didnt spend any much time on this nitty-gritty. An independent package seems more right though.

The next release will take care of these.

@Eric,
Django 1.1 support is what we are working on.

1. The DB2 Django adapter project is named ‘ibm_db_django’ (and reflected in the distribution as ibm_db_django-0.1.0.tar.gz). But then the setup.py uses ‘django.db.backends.db2’ as the name. The name field is for the project name, not a package name provided by that project, so this field should be ‘ibm_db_django’.

2. The ‘requires’ field is deprecated, and has been replaced by ‘install_requires’. The ‘requires’ field lists package names (e.g. used in import statements), while ‘install_requires’ lists project names. It’s not possible to do anything useful with a list of requires, where as a list of project’s that a project requires is quite useful. For example, ‘requires’ lists ‘django’ as a requirement … but there is no such project with that name! However, the ‘Django’ project provides the ‘django’ package.

3. This is bad:

try:
import ibm_db
import ibm_db_dbi
except ImportError:
print ”’ibm_db/ibm_db_dbi module is not installed.”’
sys.exit()

It’s sufficient to simply list the imb_db project as a dependency in ‘install_requires’. In many cases, a package can be available for import only after doing PATH manipulation, and so may be installed perfectly fine, but isn’t available for import from setup.py.

4. Google Code provides a place to release distributions, but it’s better to use PyPI for releasing all python package distributions. This way the distribution is easier to find, and it can also take advantage of any PyPI mirroring to avoid introducing a single-point of failure at installation.

5. AFAIK, the Django db backends don’t have to live within the ‘django.db.backends’ namespace. It’s probably better to put this package in it’s own namespace outside of the django.* namespaces. e.g. ‘ibm.django.db’ or some such, especially since ‘django.db.backends’ isn’t declared as a namepsace package.

Yeah, so python packaging is a bit messy – but work is being done to clean it up. If people have questions, they are welcome to ask them on the packaging mailing list (Distutils-SIG) – this is especially helpful if people can pinpoint where they are being tripped up, so that we can make the Python packaging documentation more easily understood. Ideally, a well packaged Python project shouldn’t need any installation instructions at all – people should just need to know the project name, and feed that into their installation tool of choice (Distutils, easy_install, buildout, pip).