GNU bug report logs - #55424
[PATCH 000/602] Purge Python 2 packages

Previous Next

Full log

Message #352 received at 55424 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 55424 <at> debbugs.gnu.org
Subject: Re: [PATCH 081/602] gnu: renpy: Build with Python 3.
Date: Thu, 16 Jun 2022 17:29:51 -0400

Hello,

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Donnerstag, dem 16.06.2022 um 13:11 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> 
>> 
>> [...]
>> 
>> > According to upstream, only renpy 8.0 will run on python 3, whereas
>> > renpy 7.5 (both still prereleases) will continue to use python 2.7.
>> > 
>> > I suggest "temporarily" reverting the following commits
>> > 425783b5 "gnu: Remove python2-cython."
>> > ffec658a "gnu: Remove python2-future."
>> > 1a6eb0d6 "gnu: Remove python2-pygame-sdl2."
>> > 9f1bd63f "gnu: renpy: Build with Python 3."
>> > or alternatively dropping the renpy package altogether.  I have
>> > already reverted them on my local tree, so I could push whenever –
>> > the question is whether to do it in four separate commits or in a
>> > big one along with an explanation.
>> > 
>> > WDYT?
>> 
>> Could you try updating renpy to a 8.0 pre-release?  It was last
>> updated 6 days ago [0].  That'd be preferable to re-introducing
>> Python 2 stuff.
> That looks like the kind of link that would lead to hash conflicts once
> the release is actually out (which isn't that bad normally, since I
> tend to only use actual releases).  We could use some git tag though,
> there's probably a bunch that don't map to releases.  In either case,
> these prereleases should not be used to publish game with, which makes
> packages for them kinda useless.

Pre-releases are better than a broken or missing package :-).  I guess
it depends on our users: is someone actively using the Guix-provided
renpy package to publish games?  Since the package was broken 2 weeks
ago without a bug report, I'd assume that no, in which case a
pre-release is fine and more forward-looking in this situation.

> Long-term I do think Renpy 7 should not be in Guix upstream, but past
> efforts to move it elsewhere like Guix Past ended up mere discussion. 
> The questions for me is what to do shot-term, while Renpy 8 is not a
> viable option.

Are all the above Python 2 dependencies already in the Guix-Past
channel?  If so, it seems that it could be decent option to keep renpy 7
there until renpy 8 is made stable, if updating to the pre-release in
Guix proper is too difficult.

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.