Due to manylinux deprecations, drop support for Python versions <= 3.6

[OCopping]

I propose we finally drop support for Python versions <= 3.6.

The argument for this is that now all manylinux piparch images that support Python <= 3.6 have been deprecated (as seen in https://github.com/pypa/manylinux), so supporting these is becoming untenable. This includes manylinux1 and manylinux2010, where the remaining non-deprecated and non-EOL manylinux images (manylinux2014 and manylinux_x_y) only support from Python 3.7 and above.

[mdavidsaver]

I propose we finally drop support for Python versions <= 3.6.

Why 3.6 specifically? (eg. as opposed to <= 3.7 ) Is there more than the "supported" status of manylinux images?

I am reluctant to drop support for py2.7.

... supporting these is becoming untenable.

How so?

Is it worth trying to distinguish between doing a build, and uploading the resulting wheel?

To my mind, the dynamic nature of python means if it isn't tested, then assuming it is broken will save time since it eventually will be. This would mean updating python_requires= in setup.py to prevent PIP from considering that package version for an untested python version.

[OCopping]

Why 3.6 specifically? (eg. as opposed to <= 3.7 )

The main reason behind this was down to the oldest currently supported manylinux version of manylinux2014, which states it has a minimum Python version of 3.7.8:
manylinux2014 | pip >= 19.3 | 3.7.8+, 3.8.4+, 3.9.0+

I am reluctant to drop support for py2.7.

Can I ask why you are reluctant to drop py2.7?
Surely it is about time we remove support for it as people really shouldn't be using it anymore...; There needs to be a point at which py2.7 support is thrown out, and being proactive is always better than being reactive. Not to mention it would make any future changes a lot easier to make without hack-y approaches, and would tidy the code (which I have already begun looking into in my fork).
Another big point would be the fact we could completely strip out all references to distutils and pin setuptools to be >=v70.1 (to include the wheel deprecation fix in #36 )

Is it worth trying to distinguish between doing a build, and uploading the resulting wheel?

For clarification, are you suggesting we still do the builds to test these older versions of Python, but just don't upload the wheels to PyPi? And then just stating in the setup.py the versions we actively want to support outside of the tests?

[navytux]

I am reluctant to drop support for py2.7.

For the reference I'm still using py2.7 because py3 really broke backward compatibility and it is hard, sometimes very hard, to port large applications from py2 to py3.

[OCopping]

Hi @navytux , I understand your situation but we can't keep supporting py2.7 forever. At the end of the day, it has been well over 4 years since py2.7 was fully deprecated, so there's been plenty of time to start looking into the upgrades.

I also know the pain with updating scripts to py3 (we have many old packages around Diamond Light Source I have manually been updating), but the pay-off is worth it; Neater scripts, better performance, type hinting....

You would obviously still be able to use the older versions of setuptools_dso, you just wouldn't have the benefit of getting newer additions.

[navytux]

@OCopping, thanks for feedback.

While CPython dropped py2 support, PyPy does still support both py3 and py2 as of today - see e.g. this recent announcement https://pypy.org/posts/2024/08/pypy-v7317-release.html . In my view it is a clear indicator that py2 is still being used and supported at least by some people.

Also unfortunately while there are indeed many good things in py3, it did break compatibility in major ways with respect to strings, and, in turn, it did break its documented promise that "The pickle serialization format is guaranteed to be backwards compatible across Python releases". That promise was there from 2001 (see python/cpython@f595fd975da6#diff-87dd7a103ad224116646b52862b9b744e9158c5e977fb098839e5f6d4dd2f62fR85), but loading string pickle data saved by py2 does not generally work which affects projects in around ZODB in major ways.

I have a solution for that in the works (https://lab.nexedi.com/nexedi/pygolang/-/merge_requests/21), but my main point with respect to setuptools_dso is this:

In my view whether to keep support for py2.7 or not is a matter of cost. If it only adds some small overhead, then continuing to support py2.7 is worth it as there are clear signs that it is still being used. However if supporting py2.7 adds some non-small cost, then it could be understandable the desire to drop support for it.

In my view, in the context of setuptools_dso, continuing providing support for py2.7 is likely not hard.
That's why I share @mdavidsaver attitude of being reluctant to drop support for py2.

Kirill

[mdavidsaver]

@OCopping I propose the following conditions for ending py2.7 support:

1. The (yes obsolete) manylinux1 docker images stop working on GHA.
2. No one is willing to help with py2.7 compatibility work.

I can't predict when 1) will happen. Maybe tomorrow, maybe 10 years.

As for 2) please call out if you suspect a py2.7 specific issue with a PR. I hope that @navytux or myself will be able to help within a reasonable time.