bgneal@4
|
1 Upgrading to Django 1.5
|
bgneal@4
|
2 #######################
|
bgneal@4
|
3
|
bgneal@4
|
4 :date: 2013-08-29 19:30
|
bgneal@4
|
5 :tags: Django
|
bgneal@4
|
6 :slug: upgrading-to-django-1.5
|
bgneal@4
|
7 :author: Brian Neal
|
bgneal@4
|
8
|
bgneal@4
|
9 Upgrading to Django 1.5
|
bgneal@4
|
10 =======================
|
bgneal@4
|
11
|
bgneal@4
|
12 `Django`_ 1.5 came out a while ago, and I finally got around to upgrading two
|
bgneal@4
|
13 of my largest sites. I thought I would make a list of what I changed at a high
|
bgneal@4
|
14 level for my own reference. Perhaps someone else may find it useful as well.
|
bgneal@4
|
15
|
bgneal@4
|
16 In any event, I highly recommend you read the excellent `release notes`_ and
|
bgneal@4
|
17 `deprecation timeline`_. I also recommend you run with warnings turned on::
|
bgneal@4
|
18
|
bgneal@4
|
19 $ python -Wall manage.py runserver
|
bgneal@4
|
20
|
bgneal@4
|
21 This will help you flag down issues in your code. If you aren't sure where
|
bgneal@4
|
22 a warning is coming from, you can turn warnings into exceptions and get
|
bgneal@4
|
23 a traceback (see the Python docs on the warnings_ library). Another trick is to
|
bgneal@4
|
24 put a pdb_ breakpoint in the Django code before or after the warning, then you
|
bgneal@4
|
25 can examine the call stack with the ``w`` command.
|
bgneal@4
|
26
|
bgneal@4
|
27 Upgrading Issues
|
bgneal@4
|
28 ================
|
bgneal@4
|
29
|
bgneal@4
|
30 Here are the issues that I ran into. Of course you may have a very different
|
bgneal@4
|
31 experience depending on what features of Django you used and the details of
|
bgneal@4
|
32 your site.
|
bgneal@4
|
33
|
bgneal@4
|
34 #. **Replace occurrences of Django's simplejson with json**. The Django team
|
bgneal@4
|
35 deprecated their version of the json library since they had dropped support
|
bgneal@4
|
36 for older versions of Python.
|
bgneal@4
|
37
|
bgneal@4
|
38 #. **select_related's depth argument is deprecated**. Instead of using
|
bgneal@4
|
39 ``depth`` I had to explictly name which relationships to follow.
|
bgneal@4
|
40
|
bgneal@4
|
41 #. **The cleanup management command is now called clearsessions**. I have
|
bgneal@4
|
42 a Celery_ task I had to update because of this name change.
|
bgneal@4
|
43
|
bgneal@4
|
44 #. **Remove my {% load url from future %} tags**. Long ago I had converted to
|
bgneal@4
|
45 the newer ``url`` tag behavior by using this tag. Since this is now the
|
bgneal@4
|
46 current behavior I could remove all of these tags.
|
bgneal@4
|
47
|
bgneal@4
|
48 #. **The LOGIN_* settings now accept URL names**. These settings can now accept
|
bgneal@4
|
49 URL names which allows me to be more DRY (Don't Repeat Yourself). I no
|
bgneal@4
|
50 longer have to maintain URL patterns in two places.
|
bgneal@4
|
51
|
bgneal@4
|
52 #. **Management commands should use self.stdout, etc. for output**. I'm not
|
bgneal@4
|
53 sure if this is required, but it makes it easier to test your management
|
bgneal@4
|
54 commands.
|
bgneal@4
|
55
|
bgneal@4
|
56 #. **slugify is now available at django.utils.text**. I was doing something
|
bgneal@4
|
57 kind of hacky by invoking the slugify template filter in Python code. Now
|
bgneal@4
|
58 this slugify code is more naturally available as a free Python function
|
bgneal@4
|
59 without the template filter baggage.
|
bgneal@4
|
60
|
bgneal@4
|
61 #. **Remove all references to django.contrib.markup**. Django decided not to be
|
bgneal@4
|
62 so tightly coupled to various third party markup languages. I can see their
|
bgneal@4
|
63 reasoning, as it does add to their maintenance burden, but it is kind of
|
bgneal@4
|
64 inconvenient if you already relied on it. Fortunately I had a while ago
|
bgneal@4
|
65 stopped relying on the Markdown filter and had used a custom solution.
|
bgneal@4
|
66 Seeing this issue in the release notes caused me to go looking through my
|
bgneal@4
|
67 code and I found some unused templates and ``INSTALLED_APPS`` setting that
|
bgneal@4
|
68 I could remove. On my second site, I had one tiny usage of the Textile
|
bgneal@4
|
69 filter that I decided to just get rid of since it was hardly worth carrying
|
bgneal@4
|
70 the dependency for. I wrote a quick and dirty management command to convert
|
bgneal@4
|
71 the database from storing Textile markup to HTML and I was done.
|
bgneal@4
|
72
|
bgneal@4
|
73 #. **localflavor is deprecated in preferece to a third party app**. I was using
|
bgneal@4
|
74 some US state fields in a few models. All I had to do was pip_ install
|
bgneal@4
|
75 `django-localflavor`_, fix up some imports, update my requirements files,
|
bgneal@4
|
76 and I was good.
|
bgneal@4
|
77
|
bgneal@4
|
78 #. **Function-based generic views are now gone**. A third party application
|
bgneal@4
|
79 I am using made use of the old function-based generic views. These have been
|
bgneal@4
|
80 replaced with the newer class-based generic views. Luckily I wasn't actually
|
bgneal@4
|
81 using the views in this application, I am only relying on it's models and
|
bgneal@4
|
82 utilities. In this case I simply removed the inclusion of the application's
|
bgneal@4
|
83 ``urls.py`` and all was well. The application is no longer maintained so
|
bgneal@4
|
84 I would have had to port to the class-based views if I had needed them.
|
bgneal@4
|
85
|
bgneal@4
|
86 #. **The adminmedia template tags library is now gone**. I wasn't actually
|
bgneal@4
|
87 using this anymore, but I had a template that was still loading it. This
|
bgneal@4
|
88 cruft was removed.
|
bgneal@4
|
89
|
bgneal@4
|
90 What I didn't do
|
bgneal@4
|
91 ================
|
bgneal@4
|
92
|
bgneal@4
|
93 Django 1.5's largest new feature is probably its support for a `configurable
|
bgneal@4
|
94 User model`_. This impacts my largest site, and I wasn't quite sure how to
|
bgneal@4
|
95 proceed on this front. This is the only issue I feel like Django threw me under
|
bgneal@4
|
96 the bus on. Fortunately, the ``get_profile()`` and ``AUTH_PROFILE_MODULE``
|
bgneal@4
|
97 stuff will not be removed until Django 1.7. In addition, the author of the
|
bgneal@4
|
98 South_ library is developing model migration support which will also land in
|
bgneal@4
|
99 Django 1.7. Thus there is some time to sort this out, and I'm hoping Django
|
bgneal@4
|
100 will have some tutorials or docs on how to migrate away from the old
|
bgneal@4
|
101 ``AUTH_PROFILE_MODULE`` scheme.
|
bgneal@4
|
102
|
bgneal@4
|
103 Conclusion
|
bgneal@4
|
104 ==========
|
bgneal@4
|
105
|
bgneal@4
|
106 The upgrade process went smoother and quicker than I thought thanks to the
|
bgneal@4
|
107 excellent release notes and the Django team's use of Python warnings to flag
|
bgneal@4
|
108 deprecated features.
|
bgneal@4
|
109
|
bgneal@4
|
110
|
bgneal@4
|
111 .. _Django: https://www.djangoproject.com/
|
bgneal@4
|
112 .. _release notes: https://docs.djangoproject.com/en/1.5/releases/1.5/
|
bgneal@4
|
113 .. _deprecation timeline: https://docs.djangoproject.com/en/1.5/internals/deprecation/
|
bgneal@4
|
114 .. _warnings: http://docs.python.org/library/warnings.html
|
bgneal@4
|
115 .. _pdb: http://docs.python.org/library/pdb.html
|
bgneal@4
|
116 .. _Celery: http://www.celeryproject.org/
|
bgneal@4
|
117 .. _pip: http://www.pip-installer.org/en/latest/
|
bgneal@4
|
118 .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor
|
bgneal@4
|
119 .. _configurable user model: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user
|
bgneal@4
|
120 .. _South: http://south.aeracode.org/
|