Re: Python 2 end-of-life?

[Konrad Hinsen]

Hi Bengt and Simon,

Nice discussion, please go on. With Simon taking the pragmatic point of
view ("what can we do right now?") and Bengt the long-term idealist
perspective ("where should Guix be going?"), we might end up getting
both ends right.


Bengt Richter <address@hidden> writes:

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

That's every packager's problem. We see our main job as assembling
pieces into a whole, but we should ideally also check the quality
of our building blocks. Unfortunately, that kind of responsibility
has never been valued in the tech world.

Which means that, pragmatically speaking, we'll have to do what everyone
else does: delegate quality control to the end user. Otherwise we'd have
only a hundred packages in Guix and nobody would be interested.

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

That's exactly where I want to go in the long run. The kind of analysis
I have been doing with a Guile script should be integrated into a
decent user interface, emacs-guix being the obvious candidate.
Every software system should have a scriptable user interface,
in my opinion.

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

Unfortunately that's a hard problem, given the enormous diversity of
packages in Guix. But for specific cases, it looks doable. Much like we
have various build systems for frequent special cases, we could have
inspectors for them as well.

Back to Python, I could add a check for python-build-system to
distinguish between Python libraries/applications and non-Python
code that just contains small helper scripts.

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

While I disagree with your choice of terms (top vs. lesser), I do
agree with the principle of providing empowering tools for a wide
range of users (who are not "lesser mortals" for me, but people
with a different focus).

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

Me too. Another long-term mission for Guixers (or perhaps better the
Reproducible Builds community) is education about bootstrapping.
I can understand the reasoning that led the Rust developers to their
approach, but it also shows that they are not aware that they are part
of a larger universe.

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

Yes, but the structure of the code is not very standardized. Counting
the lines of Python code in a source package is straightforward, but
knowing how important it is is a hard problem. Consider a three-module
Python package with 15 example scripts.

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

Indeed. And not just for Python. Everybody is living in dependency hell
these days. Guix could in the long run help to fix that.

Cheers,
  Konrad.