guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Python 2 end-of-life?


From: zimoun
Subject: Re: Python 2 end-of-life?
Date: Wed, 27 Nov 2019 18:28:36 +0100

Hi,

On Tue, 26 Nov 2019 at 22:52, Bengt Richter <address@hidden> wrote:

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

For example, considering rust, it is about the bootstrappability. See [1].

[1] http://guix.gnu.org/blog/2018/bootstrapping-rust/

I am interesting to know about clang/clang-runtime/llvm. Do we support
8 versions? Or version n-1 is useful to build version n?


> 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 is really hard -- nor impossible. And I am not convinced that the
tough work will pay off.


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

Do you propose to patch each time? Because I am not convinced again
that upstream will change Python to Guile.


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

To me, one path to remove unnecessary dependencies of Python2 is to
give a look package by package, try to replace the Python2 dependency
by the Python3 (if exist) and see what happens. If it does not build
because the package really uses Python2 features, figure out which
one, patch with the Python3 equivalent and submit the patch upstream.


All the best,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]