Re: Python 2 end-of-life?

[Konrad Hinsen]

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.