Re: Python 2 end-of-life?

[Bengt Richter <bokr@bokr.com>]

Hi Konrad,

On +2019-11-26 17:51:52 +0100, Konrad Hinsen wrote:
> Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
> 
> > I'd say the very first thing we should do is look at all non-Python
> > packages that depend indirectly on Python 2.
> 
> Here is an attempt at identifying them:
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (use-modules (guix packages)
>              (gnu packages)
>              (srfi srfi-1)
>              (ice-9 format))
> 
> (define (in-python2-ecosystem? package)
>   (string-prefix? "python2-" (package-name package)))
> 
> (define python2-dependent-packages
>   (fold-packages (lambda (package result)
>                    (cond ((in-python2-ecosystem? package)
>                           result)
>                          ((any in-python2-ecosystem?
>                                (filter package?
>                                        (map second
>                                             (package-direct-inputs package))))
>                           (cons package result))
>                          (else result)))
>                  '()))
> 
> (for-each (lambda (package)
>             (format #t "~a~%" (package-full-name package)))
>           python2-dependent-packages)
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> I find 313 packages (see list below). A few of them are still Python
> stuff (has "python" in the name but not "python2"), but most of them
> look like packages that are not themselves Python libraries.
> 
> Some of these packages are real heavyweights (llvm, texlive, qtwebkit,
> ...), so I'd say each package deserves a bug report of its own if we
> agree that a dependency on Python 2 should be considered a bug for a
> non-Python package.
> 
> Cheers,
>   Konrad.
> 
>

Pretty code :)
Dependencies, not so much ;-/

[ ... orig list snipped ]

I saved your post into file py2eol.txt and did:

egrep -oh '^[^@;]+' py2eol.txt|sort|uniq -c|sort -h|tail
--8<---------------cut here---------------start------------->8---
      1 zziplib
      2 ffmpeg
      2 ghc
      2 openimageio
      3 bedtools
      5 mozjs
      8 clang
      8 clang-runtime
      8 llvm
     18 rust
--8<---------------cut here---------------end--------------->8---

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?

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 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.

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.

So, since memory is cheap and processors are fast, anything that "does the job"
gets incorporated into our hacks, and trustworthiness dies of obesity ;-/

-- 
Regards,
Bengt Richter