Closed isedwards closed 4 years ago
@isedwards I have followed up with Laurie to get confirmation will feed back as soon as I hear
Just check the Molo repo on the previous vendor's github and it looks like the master branch is quite stale with about 1312 commits behind develop branch as shown below:
https://github.com/praekeltfoundation/molo-iogt/tree/master
@isedwards added note: master
at praekeltfoundation/molo-iogt
actually only has a single commit, all work that was staged in branches in this repository (when the Praekelt Foundation were working on IOGT) was instead submitted to the unicef/molo-iogt
master
branch
I also checked the unicef github repo from which the production docker images seem to be generated from and it shows the branch being checked out is {IOGT_VERSION=a6e3f08}. The link below shows more detail:
https://github.com/unicef/unicef-molo-iogt/blob/develop/Dockerfile
@isedwards added note: The unicef-molo-iogt
repository appears to be a very out of date test. It only contained two commits from an old version of praekeltfoundation/molo-iogt
. It should probably be archived to avoid any future confusion
The molo-iogt
repository contains plenty of customisation (templates, style sheets, language translations etc.), but there is not a lot of Python code.
In addition, the code is already valid Python 3 and the automated tests already run in both Python 2.7 and Python 3.6.
However, the site is likely to be running on Python 2 in production.
Another key issue is that the codebase is currently pinned to a number of old dependencies that are no longer supported (e.g. Django 1.11.29 and wagtail 1.13.4).
So, in addition to switching over to Python 3, the main task will be to start to upgrade the dependencies once we have a test database to make sure that everything continues to behave as expected.
We need to upgrade the dependencies until we reach Django 2.2 LTS and Wagtail 2.7 LTS. There will be a number of breaking changes that we'll need to investigate.
The current IoGT codebase uses Molo for scaffolding a Django application with sensible defaults, packages and configuration. From pip list, noticed several key features(apps) are bundled using Molo including commenting, polls & surveys as well as the core application etc.
However Molo requires Python (version 2.6 or 2.7) to be installed and this applies as well to the latest version released on August 13, 2020 (molo.core 10.2.7).
As part of the upgrade plan, it would be good to investigate further whether we shall continue supporting Molo or drop it considering it requires Python (version 2.6 or 2.7) which we are planning a migration from.
The summary at pypi.org/project/molo.core that say "Molo requires Python (version 2.6 or 2.7) to be installed" is incorrect.
It looks like the maintainers have not updated the package description recently.
We've seen ourselves that the molo dependencies run on Python 3.
We've also looked at the molo.core changelog and documented the following in #3:
The version of molo.core
that we are currently using is 6.10.3. The releases notes show:
The summary at pypi.org/project/molo.core that say "Molo requires Python (version 2.6 or 2.7) to be installed" is incorrect.
It looks like the maintainers have not updated the package description recently.
We've seen ourselves that the molo dependencies run on Python 3.
We've also looked at the molo.core changelog and documented the following in #3:
The version of
molo.core
that we are currently using is 6.10.3. The releases notes show:
- Python 3 is supported from version 6.3.0 onwards.
- Support for Python 2 is removed from version 8.0.0 (which also upgrades to Wagtail 2)
Makes sense now, thanks @isedwards
The default branch in the
molo-iogt
repository is thedevelop
branch, which is currently 34 commits ahead ofmaster
.Many of the recent commits on the
develop
branch have failing tests.The GitHub repository doesn't have any tags or releases, I assume we don't know for sure which version is currently used in production, but it seems reasonable to assume (at least initially) that the
master
branch is deployed to production and this is the branch that we should initially focus on upgrading to Python 3?@nathanbaleeta: Does this sound correct to you? @volloholic: Do we need to check this assumption?
Also, in order to test the upgrade thoroughly we ideally need a test database - is it possible to get hold of a production backup (we then need to be careful to remove any user accounts - we don't want a dev system to accidentally email anyone etc.)
We could do the Python 3 upgrade from the current latest commit (on the develop branch), but this latest version may not have been fully tested - it has failing tests and it could have regressions.