Re: Python 2 end-of-life?

[zimoun]

Hi Bengt,


On Fri, 29 Nov 2019 at 07:07, Bengt Richter <address@hidden> 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 <extra-language> 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