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

Previous Next

Full log

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 55424 <at> debbugs.gnu.org
Subject: Re: [PATCH 081/602] gnu: renpy: Build with Python 3.
Date: Fri, 17 Jun 2022 01:39:10 +0200

Am Donnerstag, dem 16.06.2022 um 17:29 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> 
> > [...]
> > [T]hese 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?  
If they did, we would probably be seeing folks make use of our renpy-
build-system, though I can't speak for people using Renpy on Guix to
publish non-free 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.
This does not just affect publishing though.  It also means that a
bunch of games you codes for 7.4 will not work (as expected) with Renpy
8, which might be – pardon the pun – game-breaking.

> > 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.
Only cython is currently in Guix Past, the rest needs to be added. 
Regarding renpy 8, it turns out that no tags exist in Github currently,
so we would have to guess some random commits.  That plus my already
mentioned concerns should imho be enough to consider using the actually
stable version as renpy and offer the other one as renpy-next if people
feel like breaking their stuff.  OTOH if our stance is that we really
don't want any python 2 stuff in Guix and rather have people use time
machine, I think we should loudly break the package (by removing it)
rather than silently.

Cheers

Previous Next

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