[Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?

[Erik Johnston]

On 23/05/2020 06:39, Glyph wrote:
>
>> On May 19, 2020, at 1:52 AM, Richard van der Hoff <richard at matrix.org 
>> <mailto:richard at matrix.org>> wrote:
>>
>> On 16/05/2020 06:56, Glyph wrote:
>>>
>>>
>>>> On May 15, 2020, at 8:40 PM, Craig Rodrigues 
>>>> <rodrigc at crodrigues.org <mailto:rodrigc at crodrigues.org>> wrote:
>>>>
>>>> Maybe it would be OK to do one more release of Twisted and announce 
>>>> that as the last release supporting Python 3.5, before
>>>> dropping support?
>>>
>>> Yeah; whenever we drop a Python version we should always support at 
>>> least one more release, so that people have some notice before they 
>>> lose access to the next set of security updates.
>>>
>>> Any 3.5 users on this list who would want to postpone it longer than 
>>> this?
>>>
>> Sadly we have an important customer whose servers run debian 
>> oldstable, which means we need to stay compatible with 3.5 until we 
>> can persuade them to upgrade, and it's taken a couple of years to get 
>> them off python 2.7...
>>
>> I'm not sure that should necessarily affect your plans, but I doubt 
>> we're alone in this situation.
>>
> I guess one thing I'm curious about is why your application would need 
> to be installed along with the system Python on those OS versions?  It 
> seems like a packaging strategy that ignored the fossilized versions 
> that Debian packages with the system and just built its own Python 
> would be more reliable and allow for upgrading at least most Python 
> dependencies well beyond what the system would allow by policy.  Or, 
> for that matter, why not just run in a Docker container?
>
> Matrix is a pretty big user, and so in some sense I care about this 
> specific case, but I also find the general question interesting, 
> because I have difficulty reasoning about how long to support older 
> versions of things in the modern application packaging environment 
> where containers, virtualenvs, and associated tooling make it possible 
> to effectively ignore the base environment. When & why do you have to 
> pay attention to it?
>
> -glyph


I believe in this case its a general desire to keep track of what 
packages are running and where they've come from. They basically trust 
that packages from official Debian repositories are probably safe from 
being tampered with, whereas random tarballs of code from the web are 
not safe (unless they're signed by someone they trust or whatever).

Now, I think it would be possible to get a newer version of Python on 
their infrastructure if we needed, but I'm sure there would be hoops 
that would need to be jumped through and justifications given, etc, 
which would undoubtedly take some time. So really it just means extra 
faff for them and us, especially since we're only a small part of their 
overall infrastructure.

Then there is the fact that they're not unique. While oldstable is, 
well, old, its still very much supported and so there's going to be a 
bunch of "enterprise" (for want of a better term) customers who will 
still be using it, and we'll need to go through the faff each and every 
time, which is quite tedious. Come the Autumn when oldstable stops being 
supported (or at least, goes into LTS mode), it might become easier to 
justify that it really /is/ reasonable for us to require a newer version 
of Python (and that they should really really upgrade their debian 
version, and its their own fault that they haven't and have to deal with 
faff that comes from that).

This would also be easier if debian had newer versions of python in 
backports, or someone ran a semi-official package repository which had 
them, but as far as I can tell no one does for debian.

(Of course you can argue that all the above is a bit silly from a 
security perspective, especially when you start considering virtualenvs 
and the like, but I have some sympathy for their outlook even if it is a 
pain at times).


In terms of twisted dropping support of 3.5, I guess the question is to 
what extent do you want applications to be hassle free to deploy on the 
more "enterprise" style environment? Without having followed along with 
the thread my bias would be to keep support until stretch support is 
ended in the Autumn. Though if 3.5 support is holding things back a lot 
then I can completely understand dropping it sooner.

(FWIW in Matrix/Synapse we take the view that we retain compat with 
old-but-supported dependencies, such as postgres, until/unless it starts 
being too costly in terms of maintenance and opportunity costs)


- Erik



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20200528/7573afac/attachment.htm>