From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Python 2 end-of-life? Date: Fri, 29 Nov 2019 12:41:43 +0100 Message-ID: References: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain> <20191129060732.GA1094@PhantoNv4ArchGx.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47052) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaeet-0006b4-JZ for guix-devel@gnu.org; Fri, 29 Nov 2019 06:42:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaeeq-0008DO-1c for guix-devel@gnu.org; Fri, 29 Nov 2019 06:41:57 -0500 Received: from mail-qk1-x72d.google.com ([2607:f8b0:4864:20::72d]:37693) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iaeep-00089d-OV for guix-devel@gnu.org; Fri, 29 Nov 2019 06:41:55 -0500 Received: by mail-qk1-x72d.google.com with SMTP id e187so25278364qkf.4 for ; Fri, 29 Nov 2019 03:41:55 -0800 (PST) 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 Cc: Guix Devel Hi Bengt, On Fri, 29 Nov 2019 at 07:07, Bengt Richter wrote: > > 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 ?? What do you know today? Nothing more? I do not understand your argument. Today, the usual rule is: if a package builds and passes its test-suite then it is included. Next is, if user experiences troubles, they have 2 choices: report to us and we inspect if it comes from our side and if not report upstream; or report directly to upstream and they inspect if it comes from their side and if not report to us. Therefore, I do not understand what you are talking about. If the test suite of any package is not well designed, hum?! it is not our problem but the problem of upstream. We cannot do more; expect contribute upstream to improve the situation. I mean, if you want to change how we include one package, let talk about it. But it is not related to python2 -> python3 switch, IMO. > Also -- are we talking about build-time dependency or run-time? > Is the latter a pure static image or dynamically linked? It is clearly defined by the manual [1], see the part about inputs, native-inputs, propagated-inputs. I agree that we have some packages where it is not well set. (I have in mind a recent complain by Mathieu cross-compiling.) But the usual rule is: the community commits with good faith and I trust the work already done. Again, I do not understand what you are talking about. [1] https://guix.gnu.org/manual/en/html_node/package-Reference.html#package-Reference > And lots more questions ;-) Please report them. :-) > 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 ;-) I agree. :-) Effort about which package is not reproducible and maybe why -- even if it is really hard to automated that, AFAIK; and which package does not have a clean bootstrappable path and maybe why -- easier because generally we already how which packages lead to issue: compilers. > 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. Can you describe what is the aim of such tool? There is source code living on Internet. Then to include this upstream source code, we package it which means: write pieces of code to fit our architecture and correctly set the dependencies. This upstream source code uses (lua|perl|python|name-it) language to be built and/or run. And so, why it is interesting to know how many lines? What is the final goal? Replace this by something else? Why? Reproducibility? Bootstrappability? > > > 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. Please show me the code and I will change my mind about the "reasonable approach". :-) And what do we win? More reproducibility? More bootstrappability? All the best, simon