Tuf: Decide on Python version

[lukpueh]

Description of issue or feature request:
Decide which Python versions we want to support in TUF 1.0.0.

Arguments for > 3.5:

• Python 2.7 has EOLed.
• Allows us to use type hints.
• Users who need lower versions can still use the current implementation, which we will continue to support for a while
• 3.5 isn't widely supported, see e.g. pyca/cryptography dropping support for it

Current behavior:

• TUF generally supports 2.7 and >= 3.5 (see setup.py and tests)
• The new simple metadata API requires >= 3.6 (see https://github.com/theupdateframework/tuf/pull/1112)

Expected behavior:
TBD

[jku]

I absolutely agree with killing 2.x with fire but I think this "we will continue to support [current implementation] for a while" part probably needs to be quite explicit -- in practice the first step should be very prominent python2 support deprecation with at least an estimated timeline.

The reason I'm saying this is https://pypistats.org/packages/tuf: pypistats may not be that reliable but it's one of the few usage indicators available... and it looks pretty bad for tuf, much worse than most distributions: _50% of the downloads are for python 2_.

[lukpueh]

Thanks for your quick chiming in, @jku! I'd like to dedicate #1127 to having a discussion about where and how to "be quite explicit about this". :)

[trishankatdatadog]

Datadog still needs temporary support for Python 2 at least, IIRC cc @Ofek @FlorianVeaux

[ofek]

Yes, but we are fine with pinning as long as security fixes are backported.

[joshuagl]

Datadog still needs temporary support for Python 2 at least, IIRC cc @ofek @FlorianVeaux

Can you help quantify "temporary support"? We don't really have the engineering resources on the project to support multiple versions of the codebase. Back-porting security fixes won't be very straightforward if we rearchitect the internals as has been proposed.

I'd rather avoid Python2.7 entirely, but it may be possible to get the Python 3.x features we want on a 2.7 supporting codebase by using additional dependencies. i.e. typing is available for Python 2.7.
Of course, the danger there is that we don't know how long our dependencies will continue to support an EOL version of Python.

[ofek]

Temporary means a while 😅

We're one user, please do what you wish and do not block on us. We will be fine.

[jku]

Incidentally Python 3.5 is End-Of-Life since yesterday

[joshuagl]

Note also that pip (the program) are dropping support for Python 2.7 in January 2021: https://pip.pypa.io/en/latest/development/release-process/#python-2-support

[joshuagl]

Another worthwhile item of note is that pyca/cryptography are intending to drop support for Python 2.7 sometime around December 2020 /January 2021 (see https://github.com/pyca/cryptography/issues/5359)

[MVrachev]

When and how we are going to drop support for python versions < 3.6?
We can easily submit a pr today to do that, but how we are going to announce it to our users, and how much time we will give them to update to a newer version?

I am not sure if there are other users than DataDog that use python < 3.6, but still if there are?

[joshuagl]

Good question. Per the ADR, we plan to write __new code__ targeting Python 3.6+ only.
Thus, implicitly, the refactored codebase which will eventually be released as version 1.0 will be Python 3.6+ only.

Given that Python 2.7 and 3.5 are both EOL, I hope the number of users is low. However, we are discussing how best, and how long, to support prior versions of the code (supporting older Python versions) in #1127