Python 3.x version support / dropping 3.5 and 3.6

[Gregory Szorc]

On Wed, Mar 2, 2022 at 11:09 AM Augie Fackler <raf at durin42.com> wrote:

>
>
> On Mar 1, 2022, at 2:53 PM, Raphaël Gomès <raphael.gomes at octobus.net>
> wrote:
>
>
> On 2/27/22 22:19, Gregory Szorc wrote:
>
> 6.1 will be the last release to support Python 2.7. That means 6.2 will be
> Python 3 only.
>
> Currently our Python 3 support is for 3.5-3.10.
>
> Python 3.5 dropped out of support in September 2020 and Python 3.6 in
> December 2021 (https://endoflife.date/python).
>
> Do we have any interest in dropping support for 3.5 or 3.6 in the 6.2
> release?
>
> Features of interest in 3.6:
>
> * Variable type annotations. (Annotating on <3.6 requires special syntax
> in comments)
> * Stabilization of async (unsure how much we'll adopt async though)
> * PEP 519 path protocol. This might enable us to clean up path handling
> throughout the codebase by adopting richly typed path objects with nice
> path-like primitives.
> * Enhancements to typing module to make it more useful.
>
> Features of interest in 3.7:
>
> * Postponed evaluation of type annotations (this is likely huge for
> managing startup time)
> * importlib.resources (allows us to clean up non-module file loading)
> * @dataclass and data classes
>
> I think the only in-support major distro still supporting 3.5 is Debian 9
> Stretch, which goes out of support on 2022-06-30.
>
> 3.6 is more complicated. CentOS/RHEL 7 and Ubuntu 18.04 ship Python 3.6.
> Although the former is already out of support. Ubuntu 18.04 is still in
> main support until 2023-04-03 and has security support for another few
> years.
>
> My pulse on the larger Python ecosystem is that 3.5 is mostly dead and 3.6
> is starting to wilt but not quite dead. Tons of projects dropped 3.5 in the
> past year.
>
> **So I'd like to propose dropping support for Python 3.5 in 6.2.** That
> would mean 6.1 is our last release with both Python 2.7 and 3.5 support.
>
> Agreed, I think this is cautious enough.
>
> I don't think I can in good faith recommend dropping 3.6 support at this
> time since it is still in wide use. But I do like the allure of the above
> highlighted features in 3.7 and think they could lead to a higher quality
> Mercurial and cleaner code base. If anyone else wants to make the case for
> dropping 3.6 despite its apparent use in supported distros, I'd love to
> hear it.
>
> +1
>
>
> Throwing an idea out there: we stop testing against 3.6 and don’t sweat
> breakages now that it’s EOL upstream, but accept patches from people that
> care (eg distro packagers) to keep it alive for some amount of time after
> the Python version goes EOL.
>

I suspect we'll have to keep minimal test coverage running because once
people start adding non-comment type annotations to the code base, it is
going to be difficult to police ourselves and prevent variable annotations.
(Although I suspect this specific issue can be prevented with a linter
scanning for variable annotations in the parsed token stream.) More
broadly, history has demonstrated that there's a long tail of random Python
version compatibility issues and if we drop testing, things will inevitably
break.

So I strongly believe we should have testing coverage for all supported
Python versions.

Another issue that may start biting us with 3.6 is distutils. This
transition is going to be a mess. 3.10 is already issuing a
DeprecationWarning about its future removal from the stdlib. It appears
setuptools is vendoring distutils to provide API backwards compatibility.
I'm not sure what the minimum Python is for setuptools, but pip has already
dropped 3.6 as of 22.0. And pip and setuptools are still working out
interplay issues related to distutils. I have a very strong feeling that
you'll really need to run a modern setuptools and pip to accommodate the
disutils migration. And if we're supporting 3.6 this may not be possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220302/612d0b66/attachment-0002.html>