On 23/05/2020 06:39, Glyph wrote:
On May 19, 2020, at 1:52 AM, Richard van der Hoff <rich...@matrix.org
<mailto:rich...@matrix.org>> wrote:
On 16/05/2020 06:56, Glyph wrote:
On May 15, 2020, at 8:40 PM, Craig Rodrigues
<rodr...@crodrigues.org <mailto:rodr...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
