[bug#49329,1/4] gnu: python2-renpy: Drop unused Ren'py sources.

These sources are written in Ren'py (the language) and thus not particularly
useful before renpy itself is built.  In particular, they serve no purpose
when installed without prior compilation.

* gnu/packages/game-development.scm (python2-renpy)[#:phases]<install>:
Drop installed "common" folder.
(renpy)[#:phases]<install>: Adjust comment accordingly.
---
 gnu/packages/game-development.scm | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

Hi Leo,

Just a general comment about Python 2. :-)

On Fri, 02 Jul 2021 at 15:58, Leo Prikler <leo.prikler@student.tugraz.at> wrote:

> * gnu/packages/game-development.scm (python2-renpy)[#:phases]<install>:

Is Ren’py working only with Python 2?  Or does it also work with Python
3?  Because Python 2 is EOL, officially since January 2020, if Ren’py is
Python 2 only, maybe it could go to the channel guix-past [1], soon or
later. :-) WDYT?

1: <https://gitlab.inria.fr/guix-hpc/guix-past>

Cheers,
simon

Hi simon,

Am Samstag, den 03.07.2021, 09:50 +0200 schrieb zimoun:
> Hi Leo,
> 
> Just a general comment about Python 2. :-)
> 
> On Fri, 02 Jul 2021 at 15:58, Leo Prikler <
> leo.prikler@student.tugraz.at> wrote:
> 
> > * gnu/packages/game-development.scm (python2-
> > renpy)[#:phases]<install>:
> 
> Is Ren’py working only with Python 2?  Or does it also work with
> Python
> 3?  Because Python 2 is EOL, officially since January 2020, if Ren’py
> is
> Python 2 only, maybe it could go to the channel guix-past [1], soon
> or
> later. :-) WDYT?
> 
> 1: <https://gitlab.inria.fr/guix-hpc/guix-past>
Ren'py does have a Python 3 compatibility layer, but I haven't gone
around to doing a pure Python 3 build yet.  I imagine it could also be
used with Tauthon[1], which was suggested to be used as python2
replacement in places where projects can't trivially be ported to the
newer python 3 stuffs.

Furthermore, Ren'py 8 will use Python 3 as a base.  I don't know if
it'll be backwards compatible with Ren'py 7 then – probably not.  If
not, moving Ren'py 7 to Guix-Past sounds like a good idea.

I must admit, I haven't been following the Python 2 removal plan too
closely.  Is it already time to move working leaf packages?

Cheers,
Leo

[1] https://github.com/naftaliharris/tauthon

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

> Hi simon,
>
> Am Samstag, den 03.07.2021, 09:50 +0200 schrieb zimoun:
>> Hi Leo,
>> 
>> Just a general comment about Python 2. :-)
>> 
>> On Fri, 02 Jul 2021 at 15:58, Leo Prikler <
>> leo.prikler@student.tugraz.at> wrote:
>> 
>> > * gnu/packages/game-development.scm (python2-
>> > renpy)[#:phases]<install>:
>> 
>> Is Ren’py working only with Python 2?  Or does it also work with
>> Python
>> 3?  Because Python 2 is EOL, officially since January 2020, if Ren’py
>> is
>> Python 2 only, maybe it could go to the channel guix-past [1], soon
>> or
>> later. :-) WDYT?
>> 
>> 1: <https://gitlab.inria.fr/guix-hpc/guix-past>
> Ren'py does have a Python 3 compatibility layer, but I haven't gone
> around to doing a pure Python 3 build yet.  I imagine it could also be
> used with Tauthon[1], which was suggested to be used as python2
> replacement in places where projects can't trivially be ported to the
> newer python 3 stuffs.
>
> Furthermore, Ren'py 8 will use Python 3 as a base.  I don't know if
> it'll be backwards compatible with Ren'py 7 then – probably not.  If
> not, moving Ren'py 7 to Guix-Past sounds like a good idea.
>
> I must admit, I haven't been following the Python 2 removal plan too
> closely.  Is it already time to move working leaf packages?

It sounds like the plan is in flux, but essentially yes:

https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00179.html

It seems to me that Python 2 will likely remain in Guix for some time,
but the various Python 2 packages will over time become hidden or
removed in favor of their Python 3 variants.

The Ren'Py plan is outlined here (I think?):

https://github.com/renpy/renpy/issues/2003

It sounds like it's going to be a slow (years) process for them.  Other
issues can be found here:

https://github.com/renpy/renpy/issues?q=is%3Aissue+is%3Aopen+%22python+3%22

Personally, I don't think it would be bad to add Ren'Py 7 to Guix
proper, even if it still depends on Python 2 and Python 2 libraries.
Until upstream supports Python 3, there is no other option, and for now
it sounds like we are not planning on removing all of the Python 2
libraries just yet.

If the maintenance burden becomes too great or we decide to eliminate
more Python 2 dependencies from Guix proper, we can always drop Ren'Py 7
or move it to Guix-Past along with its dependencies.  Hopefully Ren'Py 8
will bring Python 3 support sooner sooner than that, though, and we can
just drop Ren'Py 7 in favor of Ren'Py 8 at that time.

Hi Leo,

On Sat, 03 Jul 2021 at 10:35, Leo Prikler <leo.prikler@student.tugraz.at> wrote:

> I must admit, I haven't been following the Python 2 removal plan too
> closely.  Is it already time to move working leaf packages?

The Python EOL is January, 1rst 2020 [1].  So now, we are 1.5 years
ahead, so yes it seems already time to cook a plan. :-)

However, there is no consensus about such plan. ;-)  Some related
discussions:

2018-12: <https://yhetil.org/guix/20181226093812.GR2581@macbook41/>
2019-10: <https://yhetil.org/guix/CAJ3okZ33HsXxgVgK3XyVHvYUfDUrbcwBnOn7FC6=3AG_YvAUbQ@mail.gmail.com/>
2019-11: <http://issues.guix.gnu.org/issue/38420>  Failed attempt to cook something
2021-01: <https://yhetil.org/guix/86pn1pgf7z.fsf@gmail.com/>

From my understanding, the “implemented” plan is described by Maxim
here:

   <https://yhetil.org/guix/87pn1oxv0m.fsf@gmail.com/>

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

About Ren’Py 7, I do not have an opinion.  Yeah, waiting Ren’Py 8 seems
The Right Thing™ to do. :-)

Hope that helps,
simon

1: <https://www.python.org/doc/sunset-python-2/>

Hi simon,

Am Sonntag, den 11.07.2021, 10:28 +0200 schrieb zimoun:
> Hi Leo,
> 
> On Sat, 03 Jul 2021 at 10:35, Leo Prikler <
> leo.prikler@student.tugraz.at> wrote:
> 
> > I must admit, I haven't been following the Python 2 removal plan
> > too
> > closely.  Is it already time to move working leaf packages?
> 
> The Python EOL is January, 1rst 2020 [1].  So now, we are 1.5 years
> ahead, so yes it seems already time to cook a plan. :-)
> 
> However, there is no consensus about such plan. ;-)  Some related
> discussions:
I know, but to be fair, we aren't the only ones behind on the Python
removal.  Python 2 is very much a zombie at this point, still kept
alive by other (mostly dead, but some live) projects that people rely
on for various reasons.

> 2018-12: <https://yhetil.org/guix/20181226093812.GR2581@macbook41/>
> 2019-10: <
> https://yhetil.org/guix/CAJ3okZ33HsXxgVgK3XyVHvYUfDUrbcwBnOn7FC6=3AG_YvAUbQ@mail.gmail.com/
> >
> 2019-11: <http://issues.guix.gnu.org/issue/38420>  Failed attempt to
> cook something
> 2021-01: <https://yhetil.org/guix/86pn1pgf7z.fsf@gmail.com/>
> 
> From my understanding, the “implemented” plan is described by Maxim
> here:
> 
>    <https://yhetil.org/guix/87pn1oxv0m.fsf@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.

Regards,
Leo

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

>> From my understanding, the “implemented” plan is described by Maxim
>> here:
>> 
>>    <https://yhetil.org/guix/87pn1oxv0m.fsf@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.