Python 2 deprecation notice (30 days to upgrade)

As of 18 July 2019 Python 2 is officially deprecated for running CommCare HQ. The CommCare HQ team will continue to maintain backwards compatibility with Python 2 for the next one month after which we will not be able to guarantee compatibility.

This means that if your environment is still running Python 2 after the 22nd of August 2019 you may no longer be able to deploy code updates without risking compatibility issues.
The version of CommCare HQ you are running will continue to work but newer versions may be incompatible with Python 2.

We have documented the steps to upgrade using commcare-cloud: https://dimagi.github.io/commcare-cloud/changelog/0023-upgrade-to-python-3.html

2 Likes

Hi Simon!

Any chance this will affect the export tool?

Mazz

This will not impact the commcare-export tool however there will be a notification for that soon (thought there will be a longer compatibility window).

I would recommend upgrading as soon as is convenient.

I performed this update and notice that load_config.sh among other scripts still uses python 2.7. Is this expected?
Thanks

Note output from django-manage services:

Hi Ed

We haven't yet migrated commcare-cloud to python 3. This means that scripts that are run locally in commcare-cloud ((such as load_config.sh) will be run using python 2.

I have submitted a PR to change our changelog to include an optional settings change to ensure that django-manage scripts are run on python 3. To ensure that those are run on python 3, please include a line py3_run_deploy: True in fab-settings.yml.

PR for reference: Add note about running django-manage commands in python 3 by emord · Pull Request #3078 · dimagi/commcare-cloud · GitHub

1 Like

Thanks Jon, understood!
Ed

I have another question on this. In the documentation linked in the opening post: https://dimagi.github.io/commcare-cloud/changelog/0023-upgrade-to-python-3.html
it says:
"This version of CommCare must be deployed before rolling out this change: 476e3291"

Does that mean on a new installation, one has to deploy the first time using python 2.7 and only after deploying the latest code base, update to use python 3?

Hi Ed,

Good question. In case it's part of the confusion, "This version" in that statement should be interpreted as "The following version" i.e.

The following version of CommCare must be deployed before rolling out this change: 476e3291

On a new installation, however, you shouldn't have to run any of the changes in the changelog, including this one. If you use latest version of commcare-cloud to set up a new machine from scratch, it will result in the proper setup already. The changelog is only for existing installations that need a way of keeping up with the changes we make to commcare-cloud and to the standard infrastructure. This often includes any version changes to major software components (which is what the python 2.x to python 3.x upgrade is about), but is generally anything that requires the maintainer (such as you) to manually run a specific command that doesn't get run in the normal deploy script.

Hope that helps! Happy to answer further questions or try again if that didn't fully get at what you were asking.

Cheers,
Danny

1 Like

Just what I was hoping to hear, thank you Danny!
Ed

One more quick q.
So in these instructions: https://dimagi.github.io/commcare-cloud/changelog/0023-upgrade-to-python-3.html

I don't have to run step 3 - Add Python 3 virtualenv

cchq <env> ansible-playbook deploy_commcarehq.yml --tags=py3 -e 'CREATE_NEW_VIRTUALENV=1'

or step 4 - Update Python processes to use Python 3

cchq <env> update-supervisor-confs

...as I assume the scripts will automatically be deployed as v3 scripts when I run:
commcare-cloud monolith deploy-stack --first-time

Hey Ed,

That's right except for one thing—there seems to have been a minor error in the docs you were following (https://dimagi.github.io/commcare-cloud/setup/new_environment I assume): the initial setup command should be

commcare-cloud monolith deploy-stack --first-time -e 'CCHQ_IS_FRESH_INSTALL=1'

(i.e. what you had plus the -e 'CCHQ_IS_FRESH_INSTALL=1). I say minor because it would likely have just failed and then you would have to rerun it using the command right below it in the documentation which has the CCHQ_IS_FRESH_INSTALL variable and would then likely succeed. Anyway, the line above is what you should go with, and I'm changing the docs to reflect that. Thanks!

Cheers,
Danny

Thanks Danny, that explains another mystery - I've always had to run it a second time with CCHQ_IS_FRESH_INSTALL to get it working. Would someone your side correct the doc?
Regards
Ed

Glad we figured that out, Ed, and thanks for raising the questions. The docs should be updated now!

Cheers,
Danny

1 Like