bgneal@4: Upgrading to Django 1.5 bgneal@4: ####################### bgneal@4: bgneal@4: :date: 2013-08-29 19:30 bgneal@4: :tags: Django bgneal@4: :slug: upgrading-to-django-1.5 bgneal@4: :author: Brian Neal bgneal@7: :summary: Here are my notes about upgrading to Django 1.5. bgneal@4: bgneal@4: Upgrading to Django 1.5 bgneal@4: ======================= bgneal@4: bgneal@4: `Django`_ 1.5 came out a while ago, and I finally got around to upgrading two bgneal@4: of my largest sites. I thought I would make a list of what I changed at a high bgneal@4: level for my own reference. Perhaps someone else may find it useful as well. bgneal@4: bgneal@4: In any event, I highly recommend you read the excellent `release notes`_ and bgneal@4: `deprecation timeline`_. I also recommend you run with warnings turned on:: bgneal@4: bgneal@4: $ python -Wall manage.py runserver bgneal@4: bgneal@4: This will help you flag down issues in your code. If you aren't sure where bgneal@4: a warning is coming from, you can turn warnings into exceptions and get bgneal@4: a traceback (see the Python docs on the warnings_ library). Another trick is to bgneal@4: put a pdb_ breakpoint in the Django code before or after the warning, then you bgneal@4: can examine the call stack with the ``w`` command. bgneal@4: bgneal@4: Upgrading Issues bgneal@4: ================ bgneal@4: bgneal@4: Here are the issues that I ran into. Of course you may have a very different bgneal@4: experience depending on what features of Django you used and the details of bgneal@4: your site. bgneal@4: bgneal@4: #. **Replace occurrences of Django's simplejson with json**. The Django team bgneal@4: deprecated their version of the json library since they had dropped support bgneal@4: for older versions of Python. bgneal@4: bgneal@4: #. **select_related's depth argument is deprecated**. Instead of using bgneal@4: ``depth`` I had to explictly name which relationships to follow. bgneal@4: bgneal@4: #. **The cleanup management command is now called clearsessions**. I have bgneal@4: a Celery_ task I had to update because of this name change. bgneal@4: bgneal@4: #. **Remove my {% load url from future %} tags**. Long ago I had converted to bgneal@4: the newer ``url`` tag behavior by using this tag. Since this is now the bgneal@4: current behavior I could remove all of these tags. bgneal@4: bgneal@4: #. **The LOGIN_* settings now accept URL names**. These settings can now accept bgneal@4: URL names which allows me to be more DRY (Don't Repeat Yourself). I no bgneal@4: longer have to maintain URL patterns in two places. bgneal@4: bgneal@4: #. **Management commands should use self.stdout, etc. for output**. I'm not bgneal@4: sure if this is required, but it makes it easier to test your management bgneal@4: commands. bgneal@4: bgneal@4: #. **slugify is now available at django.utils.text**. I was doing something bgneal@4: kind of hacky by invoking the slugify template filter in Python code. Now bgneal@4: this slugify code is more naturally available as a free Python function bgneal@4: without the template filter baggage. bgneal@4: bgneal@4: #. **Remove all references to django.contrib.markup**. Django decided not to be bgneal@4: so tightly coupled to various third party markup languages. I can see their bgneal@4: reasoning, as it does add to their maintenance burden, but it is kind of bgneal@4: inconvenient if you already relied on it. Fortunately I had a while ago bgneal@4: stopped relying on the Markdown filter and had used a custom solution. bgneal@4: Seeing this issue in the release notes caused me to go looking through my bgneal@4: code and I found some unused templates and ``INSTALLED_APPS`` setting that bgneal@4: I could remove. On my second site, I had one tiny usage of the Textile bgneal@4: filter that I decided to just get rid of since it was hardly worth carrying bgneal@4: the dependency for. I wrote a quick and dirty management command to convert bgneal@4: the database from storing Textile markup to HTML and I was done. bgneal@4: bgneal@4: #. **localflavor is deprecated in preferece to a third party app**. I was using bgneal@4: some US state fields in a few models. All I had to do was pip_ install bgneal@4: `django-localflavor`_, fix up some imports, update my requirements files, bgneal@4: and I was good. bgneal@4: bgneal@4: #. **Function-based generic views are now gone**. A third party application bgneal@4: I am using made use of the old function-based generic views. These have been bgneal@4: replaced with the newer class-based generic views. Luckily I wasn't actually bgneal@4: using the views in this application, I am only relying on it's models and bgneal@4: utilities. In this case I simply removed the inclusion of the application's bgneal@4: ``urls.py`` and all was well. The application is no longer maintained so bgneal@4: I would have had to port to the class-based views if I had needed them. bgneal@4: bgneal@4: #. **The adminmedia template tags library is now gone**. I wasn't actually bgneal@4: using this anymore, but I had a template that was still loading it. This bgneal@4: cruft was removed. bgneal@4: bgneal@4: What I didn't do bgneal@4: ================ bgneal@4: bgneal@4: Django 1.5's largest new feature is probably its support for a `configurable bgneal@4: User model`_. This impacts my largest site, and I wasn't quite sure how to bgneal@4: proceed on this front. This is the only issue I feel like Django threw me under bgneal@4: the bus on. Fortunately, the ``get_profile()`` and ``AUTH_PROFILE_MODULE`` bgneal@4: stuff will not be removed until Django 1.7. In addition, the author of the bgneal@4: South_ library is developing model migration support which will also land in bgneal@4: Django 1.7. Thus there is some time to sort this out, and I'm hoping Django bgneal@4: will have some tutorials or docs on how to migrate away from the old bgneal@4: ``AUTH_PROFILE_MODULE`` scheme. bgneal@4: bgneal@4: Conclusion bgneal@4: ========== bgneal@4: bgneal@4: The upgrade process went smoother and quicker than I thought thanks to the bgneal@4: excellent release notes and the Django team's use of Python warnings to flag bgneal@4: deprecated features. bgneal@4: bgneal@4: bgneal@4: .. _Django: https://www.djangoproject.com/ bgneal@4: .. _release notes: https://docs.djangoproject.com/en/1.5/releases/1.5/ bgneal@4: .. _deprecation timeline: https://docs.djangoproject.com/en/1.5/internals/deprecation/ bgneal@4: .. _warnings: http://docs.python.org/library/warnings.html bgneal@4: .. _pdb: http://docs.python.org/library/pdb.html bgneal@4: .. _Celery: http://www.celeryproject.org/ bgneal@4: .. _pip: http://www.pip-installer.org/en/latest/ bgneal@4: .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor bgneal@4: .. _configurable user model: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user bgneal@4: .. _South: http://south.aeracode.org/