From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Python 2 end-of-life? Date: Fri, 29 Nov 2019 08:38:25 +0100 Message-ID: References: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain> <20191129060732.GA1094@PhantoNv4ArchGx.localdomain> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33095) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaarJ-0001tT-Vn for guix-devel@gnu.org; Fri, 29 Nov 2019 02:38:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaarH-0004AY-KF for guix-devel@gnu.org; Fri, 29 Nov 2019 02:38:33 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:47093) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaarG-0003xq-Ne for guix-devel@gnu.org; Fri, 29 Nov 2019 02:38:31 -0500 In-Reply-To: <20191129060732.GA1094@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 , zimoun Cc: Guix Devel Hi Bengt and Simon, Nice discussion, please go on. With Simon taking the pragmatic point of view ("what can we do right now?") and Bengt the long-term idealist perspective ("where should Guix be going?"), we might end up getting both ends right. Bengt Richter writes: > 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 ?? That's every packager's problem. We see our main job as assembling pieces into a whole, but we should ideally also check the quality of our building blocks. Unfortunately, that kind of responsibility has never been valued in the tech world. Which means that, pragmatically speaking, we'll have to do what everyone else does: delegate quality control to the end user. Otherwise we'd have only a hundred packages in Guix and nobody would be interested. > I think it represents more than that. It represents an instance of > a kind of system viewer/browser. That's exactly where I want to go in the long run. The kind of analysis I have been doing with a Guile script should be integrated into a decent user interface, emacs-guix being the obvious candidate. Every software system should have a scriptable user interface, in my opinion. > 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? Unfortunately that's a hard problem, given the enormous diversity of packages in Guix. But for specific cases, it looks doable. Much like we have various build systems for frequent special cases, we could have inspectors for them as well. Back to Python, I could add a check for python-build-system to distinguish between Python libraries/applications and non-Python code that just contains small helper scripts. > 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. While I disagree with your choice of terms (top vs. lesser), I do agree with the principle of providing empowering tools for a wide range of users (who are not "lesser mortals" for me, but people with a different focus). >> 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 :) Me too. Another long-term mission for Guixers (or perhaps better the Reproducible Builds community) is education about bootstrapping. I can understand the reasoning that led the Rust developers to their approach, but it also shows that they are not aware that they are part of a larger universe. >> > 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? Yes, but the structure of the code is not very standardized. Counting the lines of Python code in a source package is straightforward, but knowing how important it is is a hard problem. Consider a three-module Python package with 15 example scripts. > That's the kind of tools I hope will emerge, if it proves > feasible to reduce external dependencies that way. Indeed. And not just for Python. Everybody is living in dependency hell these days. Guix could in the long run help to fix that. Cheers, Konrad.