Move to Django 2.2

Issue #457 resolved
Ed McDonagh created an issue

Django 1.8 ended extended support in April 2018. The last series 1 release (and last to support Python 2.7 ends extended support in April 2020.

Django 2.2 LTS is supported through to April 2022.

Django 3.0 will be released in December 2019, but will only be supported until April 2021. Better to target 2.2 LTS until 3.2 LTS is available in about April 2021.

Comments (50)

  1. Ed McDonagh reporter

    Disabled pynetdicom testing for now. All other tests pass. Need to work out Python 3 testing rig on bitbucket. Refs #404, #777, #457, #530 [skip ci] Not ready for testing. Next task - move to Django 1.9...

    → <<cset e13fda4c134e>>

  2. Ed McDonagh reporter

    @David Platten (or anyone else!) - I could do with some help!

    With Django 1.9 makemigrations checks for errors before creating the database change instructions. imports various things from for the class based views. Some of the classes in make use of SingletonModels and do a preliminary check to see if the item exists.

    Which is where it all goes wrong, because the item doesn’t exist because the database doesn’t, and when we try to create it everything falls over.

    The two checks in question are in RFHighDoseAlertSettings(UpdateView): here and in SkinDoseMapCalcSettingsUpdate: here. You will notice that for the first of these, I have changed the method of checking but it makes no difference.

    We either need to not do this test, or not do it there, or something to prevent it being executed during makemigrations.

    If you want to run the code, you’ll need to create a Python 3 venv (I’m using Python 3.6), checkout the p3django1.9 branch and pip install -e path/to/openrem/folder to get the right versions of everything. Then start a new database (same with SQLite3 and postgresql) and clear out the previous migrations from openrem/remapp/migrations/0*. Then do a python makemigrations call.

    If I simply comment the two checks out, makemigrations works fine…

  3. Ed McDonagh reporter

    @David Platten @Luuk - With the same setup, I also can’t get the class-based views working with forms. I’ll carry on hitting it, but if one of you (or anyone else) can get there first, I’d very much appreciate it!

  4. David Platten

    @Ed McDonagh I’m setting up a python 3 install on my Windows test system. Do I need to install pynetdicom to test this branch? Trying to install it via pip gives an error message.

  5. Ed McDonagh reporter

    No, leave pynetdicom for now. I’m planning to start again with the new pynetdicom when I’ve got everything else up to latest Django.

  6. Ed McDonagh reporter

    Thanks @David Platten - I saw that solution at some point on my journey but didn’t try it! I think it is safe enough - I don’t think we would expect to see ProgrammingError in other circumstances.

    Now, any ideas about why there is no form component in class based form views…?

  7. David Platten

    If you comment out the “get_context_data” function in, and remove the check for admin group in the html template then the forms work (at least, the skin dose map settings one does).

    I think that the error is thrown when the “get_context_data” part of the view returns the context; this doesn’t contain any “form” data so the error is thrown. I don’t know how this is handled in the older django/python version.

  8. Ed McDonagh reporter

    Replaced all uses of admin in remapp/ due to namespace admin not being unique - turns out was duplicate import in openremproject/ Refs #457 Remaining fix before moving to 2.0 is ordered queryset in pagination.

    → <<cset 5d77f3436a41>>

  9. Ed McDonagh reporter

    Changed everything from dicom to pydicom. Attempted to remove all byte warnings - elements with VR UN are imported as bytes. Existing db data might be bytes too. Refs #457, #404, #777

    → <<cset 6bd11d6314da>>

  10. Log in to comment