From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: Python 2 end-of-life? Date: Thu, 28 Nov 2019 22:07:32 -0800 Message-ID: <20191129060732.GA1094@PhantoNv4ArchGx.localdomain> References: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:57268) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaZRd-0001ib-PM for guix-devel@gnu.org; Fri, 29 Nov 2019 01:08:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaZRV-0005Ni-TY for guix-devel@gnu.org; Fri, 29 Nov 2019 01:07:52 -0500 Received: from imta-37.everyone.net ([216.200.145.37]:43900 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaZRV-0005Az-K6 for guix-devel@gnu.org; Fri, 29 Nov 2019 01:07:49 -0500 Content-Disposition: inline In-Reply-To: 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: zimoun Cc: Guix Devel Hi zimoun, On +2019-11-27 18:35:42 +0100, zimoun wrote: > Hi Konrad, > > On Wed, 27 Nov 2019 at 08:56, Konrad Hinsen wrote: > > > > IOW, a bunch just differ by version -- I wonder how many of the > > > packages that drew in old versions could run fine with respective > > > latest versions of what they are dependent on? > > > > That's a very good question! > > Is it not cheap to replace the python2 dependency by the python3 one > and try to locally build? > The first step is probably cheap, but if you just s/python2/python3/g and it "works," what do you know? Can you even begin to trust, unless automated tests were _really_^n well designed ?? Also -- are we talking about build-time dependency or run-time? Is the latter a pure static image or dynamically linked? And lots more questions ;-) > > The snippet of code you sent helps to figure out which packages are > still using Python2. > I think it represents more than that. It represents an instance of a kind of system viewer/browser. Konrad made a new version which is even nicer, as you have probably already seen. I think it will be worthwhile to have various viewing/browsing tools that can help us do reasonable triage on where to put effort. Something that will reveal the low-hanging fruit ;-) Also, this is not just about python2 vs python3. There can be minor dependencies on perl or tcl or lua or whatever, or the language can be 95% of the source for the package. How do we know the proportions or their significance without a tool? Yeah, we can get the sources for the package manually and look at them various ways, but how long before you make yourself a viewer of some sort? But everybody can't easily whip up a useful tool. So I think it would be good for guix if the top talent would favor allocating time to making wizard tools that will empower lesser mortals to see and operate on what they can't see without the tools. Of course, (IMO :) tools should never clobber anything valuable without understandable warning, and explicit confirmation (and confirmation of having safely bailed out, for comfort :-). Having /dev/sda1 clobbered is a nuisance even if you have a backup image. Been there. Twice shy ;-) > As you said, some packages will not be updated to Python 3. Let > document it in description for example and let provide a rationale > explaining why that we put in the manual. > > > > That's yet another question: could we patch the upstream code to replace > > Python by something else that's more convenient for Guix. That may > > actually be a worthwhile approach to reduce software bloat in Guix, > > but it also shifts some of the maintenance burden from upstream to Guix. > > It does not appear to me a reasonable approach. If it could be an automated patch substitution of a pure guix function that will pass the same well-designed test suite as the python function it replaces, then I think it is entirely reasonable. We are not asking upstream to do anything, other than providing a well-designed test suite that will serve themselves well. Then the need for updates on our side would be detected as testing errors. > > > > Guix might well contribute to a long-term improvement of everyone's > > habits in this respect, by providing the bird's-eyes view of software > > systems that developers and maintainers of individual packages cannot > > have. What you describe is just the application of well-known ideas from > > software engineering (cleaning up code before it becomes unmaintainable) > > to the systems level. Which is possible because Guix turns the systems > > level into just another software layer. > > Agree! :-) > Yes, +1 for more bird's-eyes viewers ;-) > > All the best, > simon -- Regards, Bengt Richter