However, I have hit a couple of problems with version 1.4.0 that I took time to fix.
- I’m writing my code to work with all of the currently supported versions of Django – 1.4, 1.6, 1.7 – with 1.5 thrown in for good measure. I noticed the tests failing with v1.4.16. Turns out a comparison of version numbers in the tests was ranking 1.4.16 between 1.4.1 and 1.4.2. I modified my fork of the code to use the StrictVersion class for all version number checks, and that fixed the test issues.
- Along with multiple Django versions, I’m also working to be compatibile with a number of Python versions – 2.6, 2.7, 3.2, 3.3, 3.4. Once again, crispy_forms had a problem. Well, not really a problem. The package is not advertised to work with Python 3.2. Luckily, it’s an easy fix to handle the unicode literal changes that were reversed in v3.3. The key is
from __future__ import unicode_literalsat the top of each code file, and removing
ufrom each literal string.
I submitted the first fix as a pull request on the dev branch. Hopefully it will be accepted and merged. Python 3.2 compatibility has already been submitted as the subject of two different pull requests, so my code remains local.
These fixes have been applied to v1.4.0 in my fork of the package, and all are free to use this version until these issues are handled in the main repository. The github location is:
Or, one can include it in a requirements file for pip as follows:
It’s fun to contribute to a community open source project. I’ll do more of this.