diff mbox series

[bug#55424,081/602] gnu: renpy: Build with Python 3.

Message ID 20220515044629.6843-81-maxim.cournoyer@gmail.com
State Accepted
Headers show
Series Purge Python 2 packages | expand

Commit Message

Maxim Cournoyer May 15, 2022, 4:37 a.m. UTC
* gnu/packages/game-development.scm (renpy)[python]: Delete argument.
[phases]: Delete trailing #t.
[propagated-inputs]: Update the inputs to their Python 3 counterparts.
[native-inputs]: Likewise.
---
 gnu/packages/game-development.scm | 197 ++----------------------------
 1 file changed, 10 insertions(+), 187 deletions(-)

Comments

Liliana Marie Prikler June 16, 2022, 1:18 p.m. UTC | #1
Am Sonntag, dem 15.05.2022 um 00:37 -0400 schrieb Maxim Cournoyer:
> * gnu/packages/game-development.scm (renpy)[python]: Delete argument.
> [phases]: Delete trailing #t.
> [propagated-inputs]: Update the inputs to their Python 3
> counterparts.
> [native-inputs]: Likewise.
> ---
Sorry for commenting on a patch that has already been merged, but this
does not actually build renpy with Python 3, it builds the python parts
of renpy.  And although those "build" fine as a package, since they
lack tests, there is no guarantee that they work – as a matter of fact,
the actual renpy package, which failed to build against python 3 back
when I last updated the package still fails to build if I adjust the
package definition.

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?
Maxim Cournoyer June 16, 2022, 5:11 p.m. UTC | #2
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@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.

Thank you!

Maxim

[0]  https://www.renpy.org/release/8.0.0
Liliana Marie Prikler June 16, 2022, 6:51 p.m. UTC | #3
Am Donnerstag, dem 16.06.2022 um 13:11 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@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.

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.
Maxim Cournoyer June 16, 2022, 9:29 p.m. UTC | #4
Hello,

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

> Am Donnerstag, dem 16.06.2022 um 13:11 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler <liliana.prikler@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
Liliana Marie Prikler June 16, 2022, 11:39 p.m. UTC | #5
Am Donnerstag, dem 16.06.2022 um 17:29 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler@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
diff mbox series

Patch

diff --git a/gnu/packages/game-development.scm b/gnu/packages/game-development.scm
index d8725e837c..961b396ea7 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -1263,9 +1263,9 @@  (define-public python-pygame-sdl2
 (define-public python2-pygame-sdl2
   (package-with-python2 python-pygame-sdl2))
 
-(define-public python2-renpy
+(define-public renpy
   (package
-    (name "python2-renpy")
+    (name "renpy")
     (version "7.4.11")
     (source
      (origin
@@ -1284,8 +1284,7 @@  (define-public python2-renpy
            #t))))
     (build-system python-build-system)
     (arguments
-     `(#:tests? #f ; Ren'py doesn't seem to package tests
-       #:python ,python-2
+     `(#:tests? #f                      ; Ren'py doesn't seem to package tests
        #:phases
        (modify-phases %standard-phases
          (add-after 'unpack 'fix-commands
@@ -1293,8 +1292,7 @@  (define-public python2-renpy
              (substitute* "renpy/editor.py"
                (("xdg-open")
                 (string-append (assoc-ref inputs "xdg-utils")
-                               "/bin/xdg-open")))
-             #t))
+                               "/bin/xdg-open")))))
          (add-after 'unpack 'fix-include-paths
            (lambda* (#:key inputs #:allow-other-keys)
              (substitute* "module/setup.py"
@@ -1305,8 +1303,7 @@  (define-public python2-renpy
              (setenv "RENPY_CYTHON"
                      (search-input-file (or native-inputs inputs)
                                         "/bin/cython"))
-             (setenv "RENPY_DEPS_INSTALL" (string-join (map cdr inputs) ":"))
-             #t))
+             (setenv "RENPY_DEPS_INSTALL" (string-join (map cdr inputs) ":"))))
          (replace 'build
            (lambda* (#:key inputs outputs #:allow-other-keys #:rest args)
              ;; The "module" subdirectory contains a python (really cython)
@@ -1316,8 +1313,7 @@  (define-public python2-renpy
                (apply (assoc-ref %standard-phases 'build) args))
              ;; The above only builds the cython modules, but nothing else,
              ;; so we do that here.
-             (invoke "python" "-m" "compileall" "renpy")
-             #t))
+             (invoke "python" "-m" "compileall" "renpy")))
          (replace 'install
            (lambda* (#:key inputs outputs #:allow-other-keys #:rest args)
              ;; Again, we have to wrap the module installation.
@@ -1332,8 +1328,9 @@  (define-public python2-renpy
                  (apply (assoc-ref %standard-phases 'install) args))
                (copy-recursively "renpy"
                                  (string-append out site "/renpy"))
-               (delete-file-recursively (string-append out site "/renpy/common")))
-             #t)))))
+               (delete-file-recursively (string-append out site
+                                                       "/renpy/common"))))))))
+    (native-inputs (list python-cython))
     (inputs
      (list ffmpeg
            freetype
@@ -1342,11 +1339,7 @@  (define-public python2-renpy
            libpng
            (sdl-union (list sdl2 sdl2-image sdl2-mixer sdl2-ttf))
            xdg-utils))
-    (propagated-inputs
-     `(("python2-future" ,python2-future)
-       ("python2-pygame" ,python2-pygame-sdl2)))
-    (native-inputs
-     (list python2-cython))
+    (propagated-inputs (list python-future python-pygame-sdl2))
     (home-page "https://www.renpy.org/")
     (synopsis "Ren'py python module")
     (description "This package contains the shared libraries and Python modules
@@ -1355,176 +1348,6 @@  (define-public python2-renpy
 are only used to bootstrap it.")
     (license license:expat)))
 
-(define-public renpy
-  (package
-    (inherit python2-renpy)
-    (name "renpy")
-    (build-system python-build-system)
-    (arguments
-     `(#:tests? #f ; see python2-renpy
-       #:python ,python-2
-       #:modules ((srfi srfi-1)
-                  (guix build python-build-system)
-                  (guix build utils))
-       #:imported-modules ((srfi srfi-1) ,@%python-build-system-modules)
-       #:phases
-       (modify-phases %standard-phases
-         (add-after 'unpack 'fix-commands
-           (lambda* (#:key inputs outputs #:allow-other-keys)
-             (substitute* "launcher/game/choose_directory.rpy"
-               (("/usr/bin/python")
-                (string-append (assoc-ref inputs "python2")
-                               "/bin/python2")))
-             (substitute* "launcher/game/front_page.rpy"
-               (("xdg-open")
-                (string-append (assoc-ref inputs "xdg-utils")
-                               "/bin/xdg-open")))
-             (substitute* "launcher/game/project.rpy"
-               (("cmd = \\[ executable, \"-EO\", sys.argv\\[0\\] \\]")
-                (string-append "cmd = [ \"" (assoc-ref outputs "out")
-                               "/bin/renpy\" ]"))
-               ;; Projects are still created in the usual style, so we need
-               ;; to adjust the path.
-               (("cmd.append\\(self.path\\)")
-                "cmd.append(self.path + \"/game\")"))
-             #t))
-         (add-after 'unpack 'drop-game-from-paths
-           (lambda _
-             (substitute* (list "launcher/game/gui7.rpy"
-                                "launcher/game/gui7/images.py")
-               ((", \"game\",") ","))
-             #t))
-         (add-before 'build 'start-xserver
-           (lambda* (#:key inputs native-inputs #:allow-other-keys)
-             (let ((xorg-server (assoc-ref (or native-inputs inputs)
-                                           "xorg-server")))
-               (setenv "HOME" (getcwd))
-               (system (format #f "~a/bin/Xvfb :1 &" xorg-server))
-               (setenv "DISPLAY" ":1")
-               #t)))
-         (replace 'build
-           (lambda _
-             (invoke "python" "renpy.py" "launcher" "quit")
-             (invoke "python" "renpy.py" "the_question" "quit")
-             (invoke "python" "renpy.py" "tutorial" "quit")
-             #t))
-         (replace 'install
-           (lambda* (#:key inputs outputs #:allow-other-keys)
-             ;; Here we install our custom renpy program.
-             ;; After finishing this step, "out" will have the following:
-             ;; |-- bin/renpy
-             ;; `-- share/renpy ; i.e. path_to_renpy_base()
-             ;;     |-- common
-             ;;     `-- gui
-             ;;
-             ;; Note that common shares the source files that would be installed
-             ;; by python2-renpy (which are instead deleted from that package),
-             ;; but also contains their byte-compiled versions.
-             ;; On other systems, renpy_base would point to site-packages or
-             ;; even somewhere in /opt.
-             ;; The former approach is not as straightforward as it seems
-             ;; -- it causes renpy to load files twice for some weird reason --
-             ;; and the latter is impossible on Guix. Hence the detour through
-             ;; share/renpy and the custom renpy program.
-             ;;
-             ;; As a convention, other games should be installed as
-             ;; subdirectories of share/renpy in their respective outputs as
-             ;; well. This differs from the traditional layout, which is
-             ;; roughly the following:
-             ;; `-- Super Awesome Game
-             ;;     |-- game       ; <- the folder we actually want
-             ;;     |-- lib        ; compiled renpy module and dependencies
-             ;;     |-- renpy      ; yet another copy of Ren'py's code
-             ;;     |   |-- common ; the common folder from above
-             ;;     |   `-- ...    ; Python code (source + compiled)
-             ;;     |-- Super Awesome Game.py
-             ;;     `-- Super Awesome Game.sh
-             (let* ((out (assoc-ref outputs "out"))
-                    (bin/renpy (string-append out "/bin/renpy")))
-               (copy-recursively "renpy/common"
-                                 (string-append out "/share/renpy/common"))
-               (copy-recursively "gui"
-                                 (string-append out "/share/renpy/gui"))
-
-               (mkdir-p (string-append out "/bin"))
-               (copy-file (assoc-ref inputs "renpy.in") bin/renpy)
-               (substitute* bin/renpy
-                 (("@PYTHON@") (search-input-file inputs "bin/python2"))
-                 (("@RENPY_BASE@") (string-append out "/share/renpy")))
-               (chmod bin/renpy #o755))))
-
-         (add-after 'install 'install-games
-           (lambda* (#:key outputs #:allow-other-keys)
-             (define renpy (assoc-ref outputs "out"))
-             ;; TODO: We should offer a renpy-build-system to make the
-             ;; installation of Ren'py games easier.
-             (define* (install-renpy-game #:key output game name (renpy renpy)
-                                          #:allow-other-keys)
-               (let* ((name (or name (basename game)))
-                      (launcher (string-append output "/bin/renpy-" name))
-                      (share (string-append output "/share/renpy/" name)))
-                 (copy-recursively (string-append game "/game") share)
-                 (mkdir-p (string-append output "/bin"))
-                 (with-output-to-file launcher
-                   (lambda ()
-                     (format #t
-                             "#!~a~%~a ~a \"$@\""
-                             (which "bash")
-                             (string-append renpy "/bin/renpy")
-                             share)))
-                 (chmod launcher #o755)))
-
-             (install-renpy-game #:output (assoc-ref outputs "out")
-                                 #:game "launcher")
-
-             (install-renpy-game #:output (assoc-ref outputs "the-question")
-                                 #:game "the_question"
-                                 #:name "the-question")
-
-             (install-renpy-game #:output (assoc-ref outputs "tutorial")
-                                 #:game "tutorial")
-             #t))
-         (replace 'wrap
-           (lambda* (#:key inputs outputs #:allow-other-keys)
-             (let ((out (assoc-ref outputs "out"))
-                   (site (string-append "/lib/python"
-                                        (python-version
-                                         (assoc-ref inputs "python"))
-                                        "/site-packages")))
-               (wrap-program (string-append out "/bin/renpy")
-                 `("GUIX_PYTHONPATH" =
-                   (,@(delete-duplicates
-                       (map
-                        (lambda (store-path)
-                          (string-append store-path site))
-                        (cons (assoc-ref outputs "out")
-                              (map cdr
-                                   (filter
-                                    (lambda (input)
-                                      (string-prefix? "python2" (car input)))
-                                    inputs))))))))
-               #t))))))
-    (inputs
-     `(("renpy.in" ,(search-auxiliary-file "renpy/renpy.in"))
-       ("python2-renpy" ,python2-renpy)
-       ("python2-tkinter" ,python-2 "tk")
-       ("python2" ,python-2) ; for ‘fix-commands’ and ‘wrap’
-       ("xdg-utils" ,xdg-utils)))
-    (propagated-inputs '())
-    (native-inputs
-     (list xorg-server-for-tests))
-    (outputs
-     (list "out" "tutorial" "the-question"))
-    (home-page "https://www.renpy.org/")
-    (synopsis "Visual Novel Engine")
-    (description "Ren'Py is a visual novel engine that helps you use words,
-images, and sounds to tell interactive stories that run on computers and
-mobile devices.  These can be both visual novels and life simulation games.
-The easy to learn script language allows anyone to efficiently write large
-visual novels, while its Python scripting is enough for complex simulation
-games.")
-    (license license:expat)))
-
 (define-public python-pyxel
   (package
     (name "python-pyxel")