Support for Python 3.6?

[GrahamDumpleton]

What specific dependencies does the code have on Python 3.7?

Supported major Linux OS distributions such as Red Hat Enterprise Linux still ship Python 3.6 as latest version in most recent OS release, and will for some time. Requiring Python 3.7 will prevent organisations using this which need to have a supported operating system and language stack from a vendor.

[nolar]

As far as I remember, there are few function calls available in 3.7 only:

• contextvars module — the only tricky part to back-port (kind of thread-local storage, but for asyncio).
• dataclasses module — for some new branches (not yet merged; can be worked around).
• datetime.datetime.fromisoformat() — can be backported/re-implemented.
• asyncio.current_task() & asyncio.all_tasks() — instead of old asyncio.Task.all_tasks().

And maybe something else.

In fact, the only actual reason why 3.6 is not supported and the 3.7's modules/functions were not back-ported, is that we in our team started with 3.7, and there were no need (for us) to make it run with 3.6:

It is either a local developer's environment, where pyenv & similar tools provide any version of Python on demand, or it is a docker container in the Kubernetes cluster, where we are free to choose any distro (from the list of approved ones) with any version of Python, or to install our own.

As I see, 3.7 is the default Python since Ubuntu 19.04 Disco, so we can expect it to become the default one in LTS 2020.04 in one year from now — not fast though.

I am not educated enough regarding the strict LTS-distro requirements in some organisations to judge on how much 3.6 is actually unavoidable, and whether the effort to back-port the functions/modules is worth the benefit for the next 1 year.

My own focus currently is on the tests & coverage, thus pushing it towards the 1.0 release; and on some missing features for the full & rich experience: silent spy-handlers mostly, and the built-in resources support (i.e. non-CRD) — to expand the Kopf's scope of application.

So, I will probably not be able to add the 3.6-compatibility in the next couple months myself, sorry.

But the code contributions are highly welcome — ~so if you are willing to make Kopf 3.6-compatible, I will appreciate that, and will help as much as I can.~ See UPD below.

[nolar]

UPD: I was thinking on this topic for couple days. And came to the conclusion that it is better to keep Kopf with Python 3.7+, and to not port it to 3.6.

If we convert it to 3.6, all the development should go with the minimum 3.6 compatibility in mind, for years. The "batteries included" philosophy of Python has to be ignored, and the "batteries" should be either re-implemented locally, or delivered via the extra dependencies — which is not good from the software design point of view. It will also require extra effort not only for a one-time conversion, but for any future development of new features since then.

Conversion would be a good trade-off if Python 3.6 brings much wider adoption of Kopf than Python 3.7. Yet it is unclear in which cases the organisations use Kubernetes, but cannot use Python 3.7 under any circumstances (e.g. in containers/pods) — and what is the share of these cases.

I suggest that we keep this issue open, so that it is visible for others looking for Python 3.6 compatibility — they can leave their comments here.

But before making this decision (and before accepting any PRs for Python 3.6 compatibility), I would like to discuss the cases, the reasons, and to understand the context better.

[GrahamDumpleton]

I think in practice, due to Kubernetes community preferring Go, that an operator framework for Python is going to be a niche. So I think it is probably safe to close this issue as developers for mainstream applications that need an operator are going to use Go anyway. The issue is at least here to provide some context on why only Python 3.7 is supported.