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>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Python 2 end-of-life?
Date: Wed, 27 Nov 2019 08:56:41 +0100	[thread overview]
Message-ID: <m15zj54urq.fsf@ordinateur-de-catherine--konrad.home> (raw)
In-Reply-To: <20191126215145.GA1044@PhantoNv4ArchGx.localdomain>

Hi Bengt,

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

That's a very good question!

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

That's a much harder job, and I doubt it can be automatized. What I
analyze is the package definitions in Guix. They don't provide any
information on how the package uses its dependencies. They merely say
that the packager has declared some dependencies.

BTW, the number of lines of Python 2 code doesn't really matter either.
What we need to know is (1) can the Python 3 dependencies be replaced
by equivalent Python 3 dependencies and (2) are these dependencies
essential, or do they merely enable some minor extra (such as a Python
API for a C library). In the second case, the package could be split
into two.

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

That's yet another question: could we patch the upstream code to replace
Python by something else that's more convenient for Guix. That may
actually be a worthwhile approach to reduce software bloat in Guix,
but it also shifts some of the maintenance burden from upstream to Guix.

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

That's certainly true but on the other hand there is "never break a
working system". So there is a trade-off between long-term
maintainability and short-term reliability.

Guix might well contribute to a long-term improvement of everyone's
habits in this respect, by providing the bird's-eyes view of software
systems that developers and maintainers of individual packages cannot
have. What you describe is just the application of well-known ideas from
software engineering (cleaning up code before it becomes unmaintainable)
to the systems level. Which is possible because Guix turns the systems
level into just another software layer.

Cheers,
  Konrad.

  reply	other threads:[~2019-11-27  7:56 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 [this message]
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
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=m15zj54urq.fsf@ordinateur-de-catherine--konrad.home \
    --to=konrad.hinsen@fastmail.net \
    --cc=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    /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).