It’s been a few years that I maintain some python-django-* packages, as part of the maintenance of the OpenStack dashboard, Horizon. Currently, this consist of: python-django-appconf, python-django-babel, python-django-bootstrap-form, python-django-compressor, python-django-discover-runner, python-django-formtools, python-django-openstack-auth, python-django-overextends, python-django-pyscss.
By far, Django has been one of the biggest pain point. It moves too fast, deprecating its own API from one minor version to the next, at the rate of one minor release every 6 months.
As Django 1.9 was uploaded to Sid, a bunch of problems appeared. The Django 1.9 release notes explains it all: a large chunk of its API gets removed (look for “Freatures removed” in that page). I had to fix a few issues: the last one I fixed was #807346 (in django-openstack-auth), which needed 2 patches. Amusingly, the patch I wrote looks the same as what is currently under review, by one of the upstream authors. Though still have #807355 to fix, and that one is more complex. To fix it, I have to package the latest commit of django-compressor, and:
- Upgrade python-coffin to the latest version
- Package and upload django-overextends
- Get django-sekizai upgraded (I already interacted with the BTS to inform its package maintainer)
- Add hand-crafted patches (ie: not from upstream) to stop using django.utils.unittest and django.utils.importlib
Even after doing all of this, django-compressor still doesn’t build (unit test failures) with lots of errors ending with this:
File “some-path/build-area/python-django-compressor-1.6+2015.12.15.git.66feba0db5/compressor/management/commands/compress.py”, line 162, in compress
followlinks=options.get(‘followlinks’, False)):
File “/usr/lib/python2.7/os.py”, line 278, in walk
names = listdir(top)
TypeError: coercing to Unicode: need string or buffer, Origin found
I tried fixing this last one, but failed so far. (if anyone can help, please do…) This was just the upgrade from 1.8 to 1.9, and it doesn’t include some of the issues fixed earlier (when Django 1.9 was only in Experimental and easy fixes were written). All this to say: Django upgrades are always painful.
As I always say: the Linux kernel is so much more complex than this kind of Python modules, and yet, they don’t allow themselves break the userland API. Why most Python developers believe that it’s OK to do so? It isn’t possible to separate private and public API clearly in python (like it is with the kernel). So it isn’t uncommon that library users start using non-public functions, classes or methods. For that, it is understandable that there are breakages (when someone uses something that isn’t made to be used by the library users). But that’s the only case where it is, and there’s no excuse to break known used public API. Django upstream authors, if you read me, please stop breaking the world every 6 months! And no, your deprecation messages are not an excuse. If you did a design mistake in the past, that’s no excuse. Too bad… you’ll have to live with it until the end of times and find a work-around.