GNU bug report logs - #49329
[PATCH 00/??] Improve Ren'py package

Previous Next

Full log

View this message in rfc822 format

From: Chris Marusich <cmmarusich <at> gmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 49329 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com>
Subject: [bug#49329] [PATCH 00/??] Improve Ren'py package
Date: Wed, 14 Jul 2021 23:47:32 -0700

[Message part 1 (text/plain, inline)]

Leo Prikler <leo.prikler <at> student.tugraz.at> writes:

>> From my understanding, the “implemented” plan is described by Maxim
>> here:
>> 
>>    <https://yhetil.org/guix/87pn1oxv0m.fsf <at> gmail.com/>
> Using this plan as a starting point, I think renpy counts as a non-
> variant package relying on some python2-variant.
>
>> I just want to point that it is less work to transfer a functional
>> and
>> supported by upstream package than to transfer a package starting to
>> have issues.  Other said, I think it is easier to find motivation to
>> do
>> the transfer for this previous case than to do some “janitor” work
>> later.  For what my opinion is worth. :-)
> Fair enough, I could open up a merge request to have renpy in Guix Past
> "ahead of time", but OTOH I feel like `guix time-machine` offers
> similar benefits.  If we're going to *mirror* python packages, because
> they will soon be broken, I think it would also be a good idea to start
> from python2 instead of leaf packages.

I feel like keeping it all in Guix proper but vaguely "moving things
toward Python 3 wherever possible" is the best approach for now.  An
approach like the one Maxim suggested in the above link sounds good.

Moving Ren'Py to Guix-Past would be fine, I guess, but I have to admit
it feels a little strange.  After all, Ren'Py is neither stale nor
unmaintained.  However, some of its dependencies are (like Python 2),
and their plan for upgrading to Python 3 sounds like it will take years.

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Previous Next

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