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:54:10 -0800 Message-ID: <20191129065410.GB1094@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]:53879) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaaFu-0000W3-RH for guix-devel@gnu.org; Fri, 29 Nov 2019 01:59:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaaAk-0006ja-Kk for guix-devel@gnu.org; Fri, 29 Nov 2019 01:54:35 -0500 Received: from imta-37.everyone.net ([216.200.145.37]:60154 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 1iaaAk-0006cm-Ce for guix-devel@gnu.org; Fri, 29 Nov 2019 01:54:34 -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:28:36 +0100, zimoun wrote: > Hi, > > On Tue, 26 Nov 2019 at 22:52, Bengt Richter wrote: > > > egrep -oh '^[^@;]+' py2eol.txt|sort|uniq -c|sort -h|tail > > --8<---------------cut here---------------start------------->8--- > > 1 zziplib > > 2 ffmpeg > > 2 ghc > > 2 openimageio > > 3 bedtools > > 5 mozjs > > 8 clang > > 8 clang-runtime > > 8 llvm > > 18 rust > > --8<---------------cut here---------------end--------------->8--- > > > > 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? > > For example, considering rust, it is about the bootstrappability. See [1]. > > [1] http://guix.gnu.org/blog/2018/bootstrapping-rust/ > That looks horrible to me :) Don't they have a "guild disasseble" kind of thing that they could use to recover a mungeable source of the final product, and then make a self-hoster from that (even if it takes serious hacking)? > I am interesting to know about clang/clang-runtime/llvm. Do we support > 8 versions? Or version n-1 is useful to build version n? > > > > It would be really interesting if you could tweak your py2-dependent-package > > lister to show for each how many lines of py2 code are causing the py2 dependency! > > It is really hard -- nor impossible. And I am not convinced that the > tough work will pay off. > Why so hard? Is not all the information available in sources? If you wanted to do the job of preplacing a dependency with a guix/guile/bash native equivalent for a particular package manually, couldn't that be done? At least, couldn't one decide whether it was going to be easy or hard? So what tool would help you get to the information you need for that decision quickly? How would you write a wish-item for that? That's the kind of tools I hope will emerge, if it proves feasible to reduce external dependencies that way. > > > It would be a shame if half a dozen lines of python were pulling in > > all that weight if it could have been a few lines of guile or bash instead. > > Do you propose to patch each time? Because I am not convinced again > that upstream will change Python to Guile. > Yes, I would propose patching if it could be automated along the lines I suggested in my other reply to you. The trick is to find the packages for which this would be possible, so I am hoping tools to look for the low-hanging fruit will emerge. > > > The time it takes to figure out whether/how a trivial dependency can be > > eliminated is, ISTM, a major cause of gordian-knot dependency bloat -- which IMO > > in turn is a kind of RYF threat: it's effectively a free-time pay-wall. > > To me, one path to remove unnecessary dependencies of Python2 is to > give a look package by package, try to replace the Python2 dependency > by the Python3 (if exist) and see what happens. If it does not build > because the package really uses Python2 features, figure out which > one, patch with the Python3 equivalent and submit the patch upstream. That will likely be the best thing to do for a number of packages, but I would rather plug in a guix/guile/bash equivalent that passes the same well-designed (! :) test suite, where that is possible. So I am hoping for tools to help find those packages where it _is_ possible ;-) > > All the best, > simon -- Regards, Bengt Richter