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: Wed, 27 Nov 2019 18:35:42 +0100 [thread overview]
Message-ID: <CAJ3okZ3Hn9FSMHS5zYwcu9DgzwWNHzuUey1FOgG6xqtG4jzBLg@mail.gmail.com> (raw)
In-Reply-To: <m15zj54urq.fsf@ordinateur-de-catherine--konrad.home>
Hi Konrad,
On Wed, 27 Nov 2019 at 08:56, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
> > 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!
Is it not cheap to replace the python2 dependency by the python3 one
and try to locally build?
The snippet of code you sent helps to figure out which packages are
still using Python2.
As you said, some packages will not be updated to Python 3. Let
document it in description for example and let provide a rationale
explaining why that we put in the manual.
> 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.
It does not appear to me a reasonable approach.
> 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.
Agree! :-)
All the best,
simon
next prev parent reply other threads:[~2019-11-27 17:35 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 [this message]
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=CAJ3okZ3Hn9FSMHS5zYwcu9DgzwWNHzuUey1FOgG6xqtG4jzBLg@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 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).