all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Konrad Hinsen <konrad.hinsen@fastmail.net>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Python 2 end-of-life?
Date: Fri, 29 Nov 2019 13:12:33 +0100	[thread overview]
Message-ID: <CAJ3okZ1roytOM=Bnxkf1N1Bba-uuQJidn9yLomDhcqDg7CAYig@mail.gmail.com> (raw)
In-Reply-To: <m1k17j2kum.fsf@ordinateur-de-catherine--konrad.home>

Hi Konrad

On Fri, 29 Nov 2019 at 08:38, Konrad Hinsen <konrad.hinsen@fastmail.net> 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	other threads:[~2019-11-29 12:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 15:39 Python 2 end-of-life? zimoun
2019-11-21 11:46 ` zimoun
2019-11-21 12:01   ` Konrad Hinsen
2019-11-26 16:51     ` Konrad Hinsen
2019-11-26 17:50       ` Hartmut Goebel
2019-11-26 18:55         ` ng0
2019-11-27  8:28         ` Konrad Hinsen
2019-11-27 17:41           ` zimoun
2019-11-26 21:51       ` Bengt Richter
2019-11-27  7:56         ` Konrad Hinsen
2019-11-27 17:35           ` zimoun
2019-11-29  6:07             ` Bengt Richter
2019-11-29  7:38               ` Konrad Hinsen
2019-11-29 12:12                 ` zimoun [this message]
2019-11-29 11:41               ` zimoun
2019-11-29 13:42                 ` Bengt Richter
2019-11-29 14:12                   ` zimoun
2019-11-29 22:16                     ` Bengt Richter
2019-11-27 17:28         ` zimoun
2019-11-27 17:43           ` Ricardo Wurmus
2019-11-29  6:54           ` Bengt Richter
2019-11-29 11:55             ` zimoun
2019-11-28 14:40       ` Konrad Hinsen
2019-11-28 15:50         ` Hartmut Goebel
2019-11-28 18:22           ` zimoun
2019-11-21 17:28   ` Alex Griffin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ3okZ1roytOM=Bnxkf1N1Bba-uuQJidn9yLomDhcqDg7CAYig@mail.gmail.com' \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=konrad.hinsen@fastmail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.