Support Django 1.5

[pricem]

Hopefully this isn't going to be a big deal, but you never know.

[lenaqr]

Django 1.6 is out, do we want to try to go directly to 1.6 when we eventually do this so we don't have to do it twice?

[jmoldow]

I imagine we will effectively end up going directly to 1.6. But for those who work on implementing this transition, it might make sense / be easier to fix any backwards-incompatibilities from 1.4 -> 1.5 first, test with that, and then fix the 1.5 -> 1.6 incompatibilities.

[pricem]

I'm happy either way. I know Miles ran into some trouble with Django 1.6 when we accidentally installed it on his dev server. This will be much easier once we clean up our existing test suite.

[pricem]

I made a django-1.6-support branch, which is a work-in-progress. I fixed the obvious stuff. Some nontrivial things that still need to be fixed:

• Django's FormWizard interface has changed, so we have to update DataViews and CustomForms accordingly.
• The test runner fails to import our tests, claiming they come from an incorrect path such as 'esp.esp.web.tests'.
• The version of django-reversion that supports Django 1.6 does not have the fix we made to allow proxy caching. We may have to ask for it to be merged upstream.

[jmoldow]

FormWizard was changed between 1.3 and 1.4, and not in any major ways since then (as far as I can tell). And I thought we already fixed our code a while ago to support Django 1.4 FormWizard. What needs to be fixed about it?

[jmoldow]

Ah, I see. I guess we did not in fact upgrade to Django 1.4 FormWizard, and stuck with the Django 1.3 FormWizard.

[lenaqr]

The version of django-reversion that supports Django 1.6 does not have the fix we made to allow proxy caching. We may have to ask for it to be merged upstream.

That's not directly relevant to Django 1.6, is it? The version(s) that support Django 1.4 don't have that fix either. If I recall, either we're running off the latest git version, or proxy caching is currently still broken so Django 1.6 won't break anything new.

[jmoldow]

I think it's relevant insofar as we made a fix to reversion which was based off of Django 1.4 reversion, and we'll want to also make that fix to Django 1.6 reversion.

Except it looks like the change made it in. If you look at https://github.com/etianen/django-reversion/commit/0ad0004d6460908d8b882d7da1086fc77e6c9635, it lists that commit as being in the 1.8 release, which is the version that goes with Django 1.6 http://django-reversion.readthedocs.org/en/latest/django-versions.html.

[lenaqr]

Was it? I thought it was based off reversion's head.

[lenaqr]

In that case I think the answer is just to bump reversion to 1.8 (is that released now?) which includes the fixes we need.

[jmoldow]

https://github.com/etianen/django-reversion/releases/tag/release-1.8

[pricem]

Thanks, I hadn't noticed that 1.8 was there; I was looking in the django-1.6 branch.

[pricem]

I found a problem where we couldn't store the program modules in the cache anymore (there would be errors in unpickling because Django realizes that the program module handlers are not real models). My proposed solution was to alter the functions that cache program modules to cache them in ProgramModuleObj form and cast them as handlers before returning - does that make sense?

[lenaqr]

What if we make the program modules into proxy models rather than abstract models? That makes more sense anyway, since abstract models are supposed to be inherited from, not the other way around.

That kind of change could possibly cause a lot of unexpected side effects, though, so what you said might be better as a short-term change.

[jmoldow]

I've started working on the FormWizard migration. As far as I can tell, no changes are needed for CustomForms, because it was already using the Django 1.4 version of the FormWizard. So this just requires upgrading DataViews.

[pricem]

I made some progress getting more stuff to work, especially the tests. Do you have a good handle on the FormWizard upgrade or should I try to do it? (It looks like a nontrivial use of the current FormWizard since we don't have a series of form classes to use in advance.)

[jmoldow]

I should be able to handle it, but I'll let you know if I need help.

Part of what I'm doing is simplifying the FormWizard workflow to remove things that I designed badly. For example, currently the FormWizard starts out as one screen, and then dynamically adds the rest depending on which mode you choose. Besides the fact that there's only one mode right now, there's no reason the first screen needs to be part of the FormWizard, so I'm going to turn it into a static page with links to the different modes. I might be able to make similar simplifications to the rest of the FormWizard, though we may inevitably have some nontrivial uses left to deal with.

[pricem]

How is this coming along? Do you think we should try to merge this for the stable release?

[benjaminjkraft]

What's the status on this? 1.7 is releasing fairly soon, and there are lots of shiny new things in 1.6 (and 1.7) that would be nice to have at some point.

[pricem]

We have some code changes accumulated that were meant to support 1.6; I think the next step was to stop using a very old version of FormWizard, which Jordan was working on, by that's by no means the only thing left to do. (I think this is a project looking for a volunteer to finish it. Technically I'm assigned to it, but I have a lot of other things I need to do first.)

[benjaminjkraft]

Periodic poke on this; what is still needed? I don't think I know enough to work on FormWizard but it sounded like there were other things to do.

[benjaminjkraft]

Is anyone taking point on moving us to newer django? Support for Django 1.4 is expected to end in October 2015 and at the rate we've been putting out stable releases, it's entirely possible we'll only put out a single stable release between now and then, and it would be good to have this well-tested before then.

[ghost]

I am currently investigating the remaining issues with the FormWizard