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