Re: Python 2 end-of-life?

[Bengt Richter]

Hi zimoun,

On +2019-11-27 18:28:36 +0100, zimoun wrote:
> 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/
>

That looks horrible to me :)
Don't they have a "guild disasseble" kind of thing that they could use
to recover a mungeable source of the final product, and then
make a self-hoster from that (even if it takes serious hacking)?

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

Why so hard? Is not all the information available in sources?

If you wanted to do the job of preplacing a dependency with a guix/guile/bash
native equivalent for a particular package manually, couldn't that be done?
At least, couldn't one decide whether it was going to be easy or hard?

So what tool would help you get to the information you need for that decision 
quickly?
How would you write a wish-item for that?

That's the kind of tools I hope will emerge, if it proves
feasible to reduce external dependencies that way.

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

Yes, I would propose patching if it could be automated along the lines
I suggested in my other reply to you.

The trick is to find the packages for which this would be possible,
so I am hoping tools to look for the low-hanging fruit will emerge.

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

That will likely be the best thing to do for a number of packages,
but I would rather plug in a guix/guile/bash equivalent that passes
the same well-designed (! :) test suite, where that is possible.

So I am hoping for tools to help find those packages where it _is_ possible ;-)

> 
> All the best,
> simon

-- 
Regards,
Bengt Richter