Formally Deprecate Python 2.x Support

[JavaScriptDude]

As Python 2 has now been formally deprecated for over a year and is no longer receiving security updates, how about this project formally deprecate and no longer allow new release to run on Python 2. This will make maintaining the code much easier.

I just finished some querys of pypi data to see how many downloads there were of zfs-tools.

Here is the of zfs-tools downloads in last n months from PyPi:

version | 1 month | 2 months | 6 months | 12 months
2.7     | 0       | 0        | 8        | 20 
3.4     | 0       | 0        | 0        | 1
3.5     | 0       | 0        | 0        | 20 
3.6     | 0       | 2        | 3        | 13 
3.7     | 3       | 3        | 10       | 27 
3.8     | 3       | 7        | 17       | 21 
3.9     | 0       | 0        | 1        | 1   

Note: pypi does not store version information from all downloads so these numbers are a small subset of total downloads but should still be reflective of the big picture.

FYI - Data was retrieved from Google https://console.cloud.google.com/bigquery using the following SQL:

SELECT
  REGEXP_EXTRACT(details.python, r"[0-9]+\.[0-9]+") AS python_version,
  COUNT(*) AS num_downloads,
FROM `the-psf.pypi.file_downloads`
WHERE
  DATE(timestamp)
    BETWEEN DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 2 MONTH), MONTH)
    AND CURRENT_DATE()
  AND file.project = 'zfs-tools'
GROUP BY `python_version`
ORDER BY python_version

[Rudd-O]

Not a bad idea. What's the recommended way of doing that?

[JavaScriptDude]

I have never done this before but here is my idea on how to make this an intuitive process.

1. Create a new tag of Master as 0.6.5; which would be the last version to support Python 2.x.
2. Add a clear note to the project in master and PYPI that 0.6.5 is the last version to support Python 2.x and that master may no longer contain features that support Python 2.x.
3. Add deprecation warning in the main() code in Master for Python 2.x environments that state that they should use 0.6.5 or upgrade to Python 3.7.x.
4. Start accepting pull requests to bring master up to Python 3.7.10 support and ensure that 3.7.10 is the maximum version for the time being (see note below)
   • Typing support and print function calls is a good start but I'm sure there is some good checklists out there to follow. In particular the following header is a good baseline and adding type annotations to the code:

#!/usr/bin/env python
from __future__ import annotations
from __future__ import print_function

4. Once enough features are brought in to master then create a 0.7.0 tag as a logical 'major' jump.

3.7.10 Note: Python 3.7.10 has over 2.5 years of support left and I have come across some *nix distros that are still stuck at 3.7 (Eg Cygwin and Debian 10). I put a hard stop at 3.7.x for all my code bases for the time being because I have some production code running on Cygwin where using a higher release is very difficult to do.

[raketentimo]

Please don't do that (now). Our primary file server is running CentOS 7 - default python 2.7. Our "new" file servers and workstations are on RockyLinux 8: Defaulting to python 3.6.8
Current zfs supports starts with kernel 2.6.32 (!)
So deprecate it, but be aware that CentOS 7 is EOL June 30, 2024. Nobody wants to update python in a production environment.

You are developing tools for zfs - and at least I select my file server OS by the length of its EOL Date.

[Rudd-O]

I don't personally see a reason to kill py27 BUT the maintenance burden can be complicated (esp. w.r.t. types), and the oldest CentOS has had for a VERY long time Python 3.7 in the form ow EPEL. So, what is the consensus here?

[JavaScriptDude]

I'm neutral on this. Maybe hold off for now and do this once all major OS's are EOL'd off of 2.7.