Re: Python 2 end-of-life?

[Bengt Richter <bokr@bokr.com>]

Hi zimoun,

On +2019-11-27 18:35:42 +0100, zimoun wrote:
> Hi Konrad,
> 
> On Wed, 27 Nov 2019 at 08:56, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
> 
> > > 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!
> 
> 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 ??

Also -- are we talking about build-time dependency or run-time?
Is the latter a pure static image or dynamically linked?

And lots more questions ;-)

> 
> The snippet of code you sent helps to figure out which packages are
> still using Python2.
>

I think it represents more than that. It represents an instance of
a kind of system viewer/browser.

Konrad made a new version which is even nicer, as you have probably
already seen.

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 ;-)

Also, this is not just about python2 vs python3. There can be minor
dependencies on perl or tcl or lua or whatever, or the language can
be 95% of the source for the package.

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.


Of course, (IMO :) tools should never clobber anything valuable without
understandable warning, and explicit confirmation (and confirmation
of having safely bailed out, for comfort :-). Having /dev/sda1 clobbered
is a nuisance even if you have a backup image. Been there. Twice shy ;-)

> As you said, some packages will not be updated to Python 3. Let
> document it in description for example and let provide a rationale
> explaining why that we put in the manual.
> 
> 
> > 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.

Then the need for updates on our side would be detected as testing errors.

> 
> 
> > 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.
> 
> Agree! :-)
>

Yes, +1 for more bird's-eyes viewers ;-)

> 
> All the best,
> simon

-- 
Regards,
Bengt Richter