Skip to content
Nick Satterly edited this page Sep 23, 2018 · 6 revisions

Why Python 3?

Python 2 is end-of-life on 1 January 2020. We must transition off Python 2 long before that so support for Alerta on Python 2 will end on 31 August 2018.

There are many advantages to a Python 3 only code base, namely:

  • simplified code (remove multiple imports, retire six)
  • typing of method signatures and variables for static type checking
  • unicode / bytestring / string interop problems should be less
  • fewer deployment combinations to test, document and support

Note: Support for variable annotations was not added until version 3.6 in PEP-0526 so should use type comments for now.

Python 3 Support

PEP-0484 added type hints to Python. To take advantage of typing in Python 3 the following versions are recommended.

  • Minimum version: 3.5.2 (released 2016-06-27)
  • Recommended version: 3.6.1 (released 2017-03-21) or higher

Note: Python 3.5 is end-of-life on 13 September, 2020.

Migration from Python 2

It is strongly recommended not to attempt to do an "in place" upgrade of an existing Alerta 5.x (python 2.7) installation to Alert 6.x (python 3).

It is recommended to instead deploy a parallel stack for Alerta 6.x and cutover from 5.x to 6.x when ready. Both releases can point to the same database at the same time.

Examples

The following examples can be used to help understand the differences between a Python 2.7 deployment and a Python 3 deployment.

Typically, most OS releases still do not include Python 3 by default so it must be installed first.

To avoid potential conflicts with existing Python 2.7 installations it is recommended to create a Python 3 virtual environment (using the built-in venv in Python 3) and install Alerta into that. Then the WSGI configuration needs to point to the virtual environment. See the following examples for how to do this for Apache and uWSGI.

Apache Example

For Apache, ensure that the libapache2-mod-wsgi-py3 "mod_wsgi" package is installed and then the Apache configuration should use the new python-home option added to WSGIDaemonProcess directive.

In the example below, the python-home option points to the Python 3 virtual environment. eg. /opt/alerta.

Listen 8080
<VirtualHost *:8080>
  ServerName localhost
  WSGIDaemonProcess alerta processes=5 threads=5 python-home=/opt/alerta
  WSGIProcessGroup alerta
  WSGIScriptAlias / /srv/www/wsgi.py
  WSGIPassAuthorization On
</VirtualHost>

uWSGI Example

For uWSGI, to use a Python virtual environment ensure you install the uwsgi Python package into the Python 3 virtual environment. For example, if the virtual environment is in /opt/alerta then to install uwsgi run:

$ /opt/alerta/bin/pip install uwsgi

The uwsgi runtime that is installed in the bin subdirectory of that virtual environment is used to in any "init" script. In the example below, the uwsgi runtime in the /opt/alert virtual environment is executed by either a systemd/initd script (see Ubuntu) or something like supervisord (see Docker).

/opt/alerta/bin/uwsgi --ini /etc/uwsgi.ini

References