Re: add DEPRECATION grace period: the upcoming Great Python2 Purge™
Hello everyone! Leo Famulari writes: > On Wed, Dec 26, 2018 at 02:33:55PM +0100, Pjotr Prins wrote: >> A lot of software outside Guix still depends on Python2, for better or >> worse. I don't believe EOL means they are going to drop security >> updates. Leaf packages may well be in use today. > > I do think it means that the current Python team at python.org will stop > issuing security updates for Python 2. [0] > > Previously, Guido van Rossum said "The way I see the situation for 2.7 > is that EOL is January 1st, 2020, and there will be no updates, not even > source-only security patches, after that date. Support (from the core > devs, the PSF, and python.org) stops completely on that date." [1] > > Well, Guido is no longer involved with Python, so maybe the situation > has changed. In any case, I think we can expect third parties like Red > Hat to keep maintaining Python 2 for some years, and we can use their > work. > I suggest everyone to read these two LWN articles[0][1]. IMO, we should start deprecating all python 2 packages which are already available in python 3 and are not dependencies of python-2-only packages(*). Also, we should not create python 2 definition for new python packages anymore. Of course, we can make an exception if there's a demand for it. This way, we can start warning everybody that python 2 is going EOL and support is going to be dropped gradually. Right now, 'guix refresh -l python2' shows there're 1692 packages depending on python 2. For security updates, as Guido has mentioned python devs will no longer provide security updates after 1/1/2020, which others seemed to agree. You can read the whole thread here[2]. However, centos and debian will still be supporting python 2 past that date. Centos will support python 2 until 2024 and I suspect Debian will have to support it for even longer since their next stable release (Debian 10 on 2020) will include python 2. Cheers, Alex (*): Should we make a new construct that does it? Also, I think we should mention it in the guix blog, so others can learn about the deprecation. [0]: https://lwn.net/Articles/756628/ [1]: https://lwn.net/Articles/750833/ [2]: https://www.mail-archive.com/python-dev@python.org/msg100031.html >> Is there a way we mark packages as DEPRECATED? I think we should not >> just remove packages without a grace period. Deprecate for, say, 3 >> months or even 6 months is the way to do this. A deprecation tag >> should include a time stamp that gives the (planned) removal time. > > Not exactly, although there is a 'deprecated-package' procedure that > accepts a replacement package to supersede the deprecated package. It > doesn't do what you suggest. > > [0] Already, the status of Python 2 is 'bugfix'. If it reaches "end > of life", the bugfixing activity will presumably cease, although they do > describe another 'security' status that seems lesser than 'bugfix': > https://devguide.python.org/#status-of-python-branches > > [1] > https://mail.python.org/pipermail/python-dev/2018-March/152348.html signature.asc Description: PGP signature
Re: add DEPRECATION grace period: the upcoming Great Python2 Purge™
On Wed, Dec 26, 2018 at 02:33:55PM +0100, Pjotr Prins wrote: > A lot of software outside Guix still depends on Python2, for better or > worse. I don't believe EOL means they are going to drop security > updates. Leaf packages may well be in use today. I do think it means that the current Python team at python.org will stop issuing security updates for Python 2. [0] Previously, Guido van Rossum said "The way I see the situation for 2.7 is that EOL is January 1st, 2020, and there will be no updates, not even source-only security patches, after that date. Support (from the core devs, the PSF, and python.org) stops completely on that date." [1] Well, Guido is no longer involved with Python, so maybe the situation has changed. In any case, I think we can expect third parties like Red Hat to keep maintaining Python 2 for some years, and we can use their work. > Is there a way we mark packages as DEPRECATED? I think we should not > just remove packages without a grace period. Deprecate for, say, 3 > months or even 6 months is the way to do this. A deprecation tag > should include a time stamp that gives the (planned) removal time. Not exactly, although there is a 'deprecated-package' procedure that accepts a replacement package to supersede the deprecated package. It doesn't do what you suggest. [0] Already, the status of Python 2 is 'bugfix'. If it reaches "end of life", the bugfixing activity will presumably cease, although they do describe another 'security' status that seems lesser than 'bugfix': https://devguide.python.org/#status-of-python-branches [1] https://mail.python.org/pipermail/python-dev/2018-March/152348.html signature.asc Description: PGP signature
add DEPRECATION grace period: the upcoming Great Python2 Purge™
On Wed, Dec 26, 2018 at 01:30:53PM +0100, Marius Bakke wrote: > Efraim Flashner writes: > > > We're now about a year out from the official EOL for python2 (Jan 1, > > 2020). So far we've been not adding python2 variants of packages that > > are new unless they're actually needed for something. Do we want to > > start removing python2 packages when updating other packages if they are > > leaf packages? > > I think it's okay to start removing "leaf" Python 2 packages. In most > cases they were probably never used anyway, or the dependents have > transitioned to their Python 3 counterparts. > > We'll probably break some channels, but I'm sure our users won't have > any difficulties adding them back to their own channels if need be. > > On a related note, we also have a number of [Python 3] packages that > have been failing to build for a long time. Some of these are trivial, > i.e. what "guix import" produces. > > It would be good to get rid of those as well, as the would-be user is > much better off starting from "guix import" instead of first getting > disappointed by the Guix package and then having to go through all the > trouble of submitting a patch. > > Should we have some sort of policy or threshold for when to remove such > packages? Maybe after 3-6 months? A lot of software outside Guix still depends on Python2, for better or worse. I don't believe EOL means they are going to drop security updates. Leaf packages may well be in use today. Is there a way we mark packages as DEPRECATED? I think we should not just remove packages without a grace period. Deprecate for, say, 3 months or even 6 months is the way to do this. A deprecation tag should include a time stamp that gives the (planned) removal time. Pj.
