A taste of what's involved in upgrading Django, and why we shouldn't do it yet.

[James Bennett]

tl;dr in advance: we should not upgrade to Django 1.3. We should wait
for 1.4 to land, and possibly 1.4.1 to shake out bugs, then upgrade to
that.

What follows is the details of why :)


The investigation bug for this was time-boxed, so I basically just
started trying to run the test suite on 1.3 and figure out what broke,
fixing problems as I went until I hit the time limit.

The first problem is that django.utils.thread_support, due to Django's
changed Python version requirements, no longer exists as of
1.3. devmo/urlresolvers tries to import from this and fails.

This means anything which imports devmo.urlresolvers.reverse blows up
under 1.3.

Amusingly, in bug 695774 we investigated switching to sumo's
reverse(); sumo does not have this problem, since it uses the built-in
Python threading module directly. We WONTFIX'd that at the time, since
it didn't seem to offer any benefit. So when we do eventually upgrade
our Django, we'll want to either reopen that bug and just switch to
sumo's reverse(), or make the (fortunately relatively small) change to
devmo's reverse() to also use the threading module directly.

Fixing that leads into the next problem, which is that our existing
logging facility conflicts with the one available as of Django 1.3. We
use a setting named LOGGING for this, which is a dictionary of
configuration for our logging; Django 1.3 also uses a setting named
LOGGING for this, and bails when it can't find the appropriate keys in
the dictionary for how Django's built-in logging is configured.

Fixing this one is trickier; our options here are to switch over to
Django's native logging support, or rewrite a bit so that we use a way
of configuring our logging that doesn't clash with Django.

When I ran out of testing time, I was taking the first option there,
and just setting up a logging config that matches Django's expected
format. The test suite was still unable to bootstrap, though.

One other thing worth noting is that we'll want to carefully review
how we manage files, since Django now does not auto-cleanup orphaned
files for us.

Anyway. This is how the upgrade's going to work, though that is of
course no surprise; my guesstimate for getting the full test suite to
run and report failures, is a bit more than a 2-pointer but maybe not
a full 3. The uncertainty is mostly due to the suite of other stuff
that ought to upgrade at the same time, and not knowing yet exactly
how many of those little fixes (each probably eating between 30-60
minutes to nail down, fix and test) need to happen along the way.


---


So. Is it worth it to go to 1.3? Probably not right now. The big wins,
feature-wise, in Django 1.3 would be

* Incredibly better unit testing, but we're already not really using
Django's own testing facilities. Also, taking advantage would
require rewriting a bunch of tests.

* First-class support for class-based views. This could, I'm pretty
sure, simplify the way some of the wiki code works, but migrating to
class-based views would be a bit of a project. 1.3 also deprecates
the old generic views, which we do use in places, but they don't get
removed from Django until 1.5.

Most of the rest of the features in 1.3 aren't really worth getting
excited about.

Given the work involved, and the fact that the stuff we'd take
advantage of requires even more work, I think we should just skip 1.3
and go straight to 1.4.

1.4 is much more interesting to us, because it ships:

* Built-in support for locale-prefixed URLs and translatable URLs,
including reverse()-type helpers that are aware of this.

* Built-in support for Selenium and in-browser testing.

* The new PASSWORD_HASHERS setting, which lets us stop monkeypatching
contrib.auth to do better hashing.

* Far better/more secure cookie-based sessions and cookie handling in
general, and really just a crap ton of security improvements.

We will want to investigate carefully the way that Django's
crypto/signing stuff has changed to make sure we don't lose anything
generated by older versions, but that's not likely to bite us in any
big way.


---


So there we are. We *could* go to Django 1.3, but it just really isn't
worth our time. When it comes out, 1.4 *will* be.

[Luke Crouch]

Cool, I vote for 1.4.1. Sounds like we can file it for later and file
some dependency bugs? I.e.,

* re-open bug 695774
* refactor logging code
* investigate orphan file issues

And then follow-up bugs that are blocked by the ugprade:

* investigate: django locale-prefixed URL's
* investigate: use PASSWORD_HASHERS setting (not needed with BrowserID?)
* bug 698427

Sound right?

-L

> _______________________________________________
> dev-mdn mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdn

[Luke Crouch]

https://bugzilla.mozilla.org/showdependencytree.cgi?id=731209&hide_resolved=1

-L