From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Python 2 end-of-life? Date: Wed, 27 Nov 2019 08:56:41 +0100 Message-ID: References: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36062) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZsBs-0005Gq-PB for guix-devel@gnu.org; Wed, 27 Nov 2019 02:56:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZsBr-0000Po-Kd for guix-devel@gnu.org; Wed, 27 Nov 2019 02:56:48 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:42999) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZsBr-0000MI-5V for guix-devel@gnu.org; Wed, 27 Nov 2019 02:56:47 -0500 In-Reply-To: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain> 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: Bengt Richter Cc: Guix Devel Hi Bengt, > 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! > 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! That's a much harder job, and I doubt it can be automatized. What I analyze is the package definitions in Guix. They don't provide any information on how the package uses its dependencies. They merely say that the packager has declared some dependencies. BTW, the number of lines of Python 2 code doesn't really matter either. What we need to know is (1) can the Python 3 dependencies be replaced by equivalent Python 3 dependencies and (2) are these dependencies essential, or do they merely enable some minor extra (such as a Python API for a C library). In the second case, the package could be split into two. > 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. 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. > 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. That's certainly true but on the other hand there is "never break a working system". So there is a trade-off between long-term maintainability and short-term reliability. 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. Cheers, Konrad.