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: Fri, 29 Nov 2019 13:12:33 +0100

Hi Konrad

On Fri, 29 Nov 2019 at 08:38, Konrad Hinsen <address@hidden> wrote:

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

Thank you for this kind words. :-)


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

I agree.


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

Delegate the quality control first to the test suite and second to the end user.

Proposing an automated testing framework free of any underlining
language is impossible, IMHO.

Even if I am personally interested in how to efficiently test the code
-- the QuickCheck [2] approach is really interesting and the CakeML
[2] even more :-) -- I am not sure this goal fits the purpose of Guix.
I mean, Guix cannot fix the broken world. ;-) And it already fixes a
lot of things...


[1] http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html
[2] https://cakeml.org/



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

I agree that we are lacking of tools. And our tooling should be improved a lot!

What kind of metrics do you want with such "script"? And metrics to
inform about which goal?


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

AFAIK it is worse in the Haskell world. ;-) Ricardo tried [3] and some
Haskellers spoke [4] about the issue but I have not seen any
initiative from the Haskell community.


[3] https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html
[4] https://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC


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

Guix fixes that! (overseeling? ;-)


Cheers,
simon



reply via email to

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