unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Konrad Hinsen <konrad.hinsen@fastmail.net>
To: Bengt Richter <bokr@bokr.com>, zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Python 2 end-of-life?
Date: Fri, 29 Nov 2019 08:38:25 +0100	[thread overview]
Message-ID: <m1k17j2kum.fsf@ordinateur-de-catherine--konrad.home> (raw)
In-Reply-To: <20191129060732.GA1094@PhantoNv4ArchGx.localdomain>

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 <bokr@bokr.com> 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.

  reply	other threads:[~2019-11-29  7:38 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 [this message]
2019-11-29 12:12                 ` zimoun
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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=m1k17j2kum.fsf@ordinateur-de-catherine--konrad.home \
    --to=konrad.hinsen@fastmail.net \
    --cc=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).