From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nils Gillmann Subject: Re: Python 2 retirement =?utf-8?B?4oCU?= what should Guix do? Date: Sat, 16 Jun 2018 18:30:55 +0000 Message-ID: <20180616183055.kal6urc6srrn7ikl@abyayala> References: <20180616180118.GA9585@jasmine.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUFxt-0000za-Gj for guix-devel@gnu.org; Sat, 16 Jun 2018 14:30:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUFxs-0007gt-BY for guix-devel@gnu.org; Sat, 16 Jun 2018 14:30:21 -0400 Received: from conspiracy.of.n0.is ([2a01:4f8:1c0c:7ad0::1]:44718) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fUFxs-0007fi-2E for guix-devel@gnu.org; Sat, 16 Jun 2018 14:30:20 -0400 Content-Disposition: inline In-Reply-To: <20180616180118.GA9585@jasmine.lan> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari Cc: guix-devel@gnu.org Leo Famulari transcribed 1.9K bytes: > In 2020, Python 2 will no longer be supported by the Python team. [0] > > To quote Guido van Rossum, "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] > > In Guix we aim to offer software that is safe to use, which typically > means "maintained". > > Presumably, Python 2 will be maintained by some third parties for quite > a while after 2020. > > I wonder, what should Guix do? > > Personally, I think our set of Python packages is relatively hard to > maintain. There is a lot of brittle code in there. I'd be happy to drop > our policy that Python libraries have both Python 2 and 3 packages by > default. > > [0] > https://legacy.python.org/dev/peps/pep-0373/ > > [1] > https://mail.python.org/pipermail/python-dev/2018-March/152348.html While I agree with the security aspect, I don't think the goal to drop python-2 by 2020 on OS site is realistic at all. We can do it, but we will have lots of people out there relying on python-2. When a language implementation reached EOL, we don't have to follow that. Personal misery: I seem (at the moment) to be the only GNUnet dev trying to move whatever python2 code we have in all projects around and in GNUnet to python2+3 dual support, and that's not even fulltime. 2020 might be doable, but who knows what life throws at you. It could be reasonable to do the following: - Jan 2020. Python drops 2 support. - Also Jan 2020: we document an emphasis on prefering python3 packages, or even the recommendation to help upstream to make the software build with python3. If there's nothing special going on, it is rather trivial but nevertheless can take some time. We keep python-2 around. We announce a feature freeze, starting Jan 2021, on the python2 part of python packages which exist in both versions if they are build from the same source. - Jan 2021: We no longer accept python-2 packages unless it is for a specific reason, case-by-case decision. - 2022: Drop python-2? I'm really in favor of keeping it around but leaving it as a conscious decision for people who need it. That's what I do for the kernel for example. I bump versions, I try to maintain the official supported versions but leave versions and package recipes of older versions around. Whoever needs older versions will be aware of the implications that come with these older versions. Of course it is really tempting to get to a system which only supports one implementation of the python language, and thus get rid of some code. If we were the size of Debian, we could even shape the process and adoption by option to no longer support the dual scheme. Of course because we are not the size of Debian, it is also easier to decide what we do. I think full-time python devs such as Hartmut will have more to say about this.