On 04/21/2018 07:57 PM, Adrian Bunk wrote: > Hi, > > first two facts: > > 1. Upstream EOL for Python 2 is 2020 > > 2. Debian will fully (security) support Python 2 in buster > until the EOL of buster (ETA: mid-2022) > > > Python 2 is obsolete, no doubt about that. > > But in many cases a Linux distribution is just a platform for running > own applications, and for various good and bad reasons many of our > users will have to support custom and/or 3rd party Python 2 code on > systems running buster. > > We are only making it unnecessarily harder for our users when > Python 2 modules are dropped before buster. > > The tip of the iceberg are some recent cases where Python 2 modules > were dropped that still had reverse dependencies in unstable, but > also for those without there will in many cases be users who will > still need these modules in buster. > > > All of the above applies especially in cases where continuing to > provide a Python 2 module does not cause problems or extra work > (in several cases Python 2 modules were dropped in a new Debian > revision of a package without any real reason). > > There are of course cases (e.g. OpenStack) where providing Python 2 > modules in buster is not possible with reasonable effort.
OpenStack isn't any different from other Python app/modules. I simply happened to flip the switch, and made every service run on top of Python 3. And right now, it bites hard, because I have to fix all puppet modules to run using Python 3 instead of 2. It's far from trivial, unfortunately. So, as I wrote, it's not any different. Once you've switched, why keeping the legacy? Isn't 10 years of Python 3 enough time for a migration? What's the incentive? Bit rotting legacy code? This code is already not maintainable, and that's the issue that should be addressed. Right now, the only reason I'm keeping Python 2 support within a number of packages in OpenStack, is because one of our team member wrote he's using Python 2 in his company, and that we never finished the conversation as to when we can remove that support. So we're doing here a favor, but I'm not sure that's a favor to Debian. To the contrary, this means we're keeping the legacy, and prevent clean-ups. Also, I have noticed that when removing Python 2 legacy packages, a lot of cruft remains in the archive. This isn't trivial to track and clean. I'd love to have the opinion of the FTP master team about this. How can we file sensible bugs about it? How can I track what hasn't been un-crufted? Last: it is my opinion here that you're sending a very wrong message in the wrong direction that opposes to the general consensus within the Python team. Maybe it would have been wiser to discuss with that team first, before raising the thread in debian-devel. Anyway, thanks for your tireless bug reports. Their value cannot be overstated. Cheers, Thomas Goirand (zigo)
