--- Begin Message ---
Subject: |
[PATCH] gnu: Add pypy3. |
Date: |
Sat, 23 May 2020 08:56:48 +0200 |
Hi,
the attached patch adds pypy3, a Python 3 JIT. As you can see this is a
lot of work, because pypy’s build system is rather unconventional. I’m
not adding pypy2, because Python 2 is essentially EOL.
I’ve tried fixing as many testcases as possible, but there are some I
don’t know how to fix. Thus I’m disabling the test suite, although
everything is in place to run it. pypy itself works fine though, the
build is reproducible and passes `guix lint`.
One thing I don’t like right now is the dependency on gcc-toolchain
(i.e. gcc and binutils) in distutils. I don’t know how to avoid that,
since building CFFI modules won’t work without patching.
I guess the next step would be figuring out how to add “pypy3-foo”
variants for our Python packages, right?
Cheers,
Lars
0001-gnu-Add-pypy3.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
Subject: |
Re: [bug#41472] [PATCH] gnu: Add pypy3. |
Date: |
Mon, 01 Jun 2020 00:46:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi,
Lars-Dominik Braun <lars@6xq.net> skribis:
>> > One thing I don’t like right now is the dependency on gcc-toolchain
>> > (i.e. gcc and binutils) in distutils. I don’t know how to avoid that,
>> > since building CFFI modules won’t work without patching.
>> Is CFFI able to pick ‘gcc’ from $PATH? If it can do it, we can avoid
>> hardcoding the absolute file name of GCC and instead leave it up to the
>> user to add GCC to their environment when they want to use CFFI.
> yes, it is, but it looks for the executable "cc", which – oddly – our
> gcc-toolchain does not provide. Is this intentional?
Yes: as discussed elsewhere, GCC does not provide ‘cc’, and we don’t
provide it either.
> The updated patch replaces it with gcc, which seems to work.
Perfect.
>> The advice seems to be very general; did you mean that people should
>> look for something specific in the build log, for example because test
>> failures are silently ignored?
> No, not really. Just to run the disabled test suite and see if it goes
> from “a few failures” to “everything is broken now”. I could selectively
> patch the testsuite to disable currently failing tests, but I’m not
> competent enough to judge which one can be skipped safely (due to
> sandboxing limitations for example) and which indicate an actual
> failure. I’ll remove the comment.
OK.
Alright. I took the liberty to make the changes below and committed.
Thanks!
Ludo’.
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index b399931a42..9469f89bcf 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -673,7 +673,7 @@ ease from the desktop to a microcontroller or embedded
system.")
("bash-minimal" ,bash-minimal) ; Used as /bin/sh
("xz" ,xz))) ; liblzma
(arguments
- `(#:tests? #f ; Disabled for now, there are simply too many unfixable
tests failing
+ `(#:tests? #f ;FIXME: Disabled for now, there are many tests failing.
#:modules ((ice-9 ftw) (ice-9 match)
(guix build utils) (guix build gnu-build-system))
#:phases (modify-phases %standard-phases
@@ -782,19 +782,18 @@ ease from the desktop to a microcontroller or embedded
system.")
"pypy-dist/lib-python/3/encodings/rot_13.py")
(("#!.+/bin/python")
(string-append "#!" (assoc-ref outputs "out")
"/bin/pypy3")))
- (with-fluids
- ((%default-port-encoding "ISO-8859-1"))
- (substitute*
- '("pypy-dist/lib_pypy/_md5.py"
"pypy-dist/lib_pypy/_sha1.py")
- (("#!.+/bin/python")
- (string-append "#!" (assoc-ref outputs "out")
"/bin/pypy3"))))
+ (with-fluids ((%default-port-encoding "ISO-8859-1"))
+ (substitute* '("pypy-dist/lib_pypy/_md5.py"
+ "pypy-dist/lib_pypy/_sha1.py")
+ (("#!.+/bin/python")
+ (string-append "#!" (assoc-ref outputs "out")
"/bin/pypy3"))))
(copy-recursively "pypy-dist" (assoc-ref outputs
"out")))
#t)))))
(home-page "https://www.pypy.org/")
(synopsis "Python implementation with just-in-time compilation")
(description "PyPy is a faster, alternative implementation of the Python
-programming language employing a just-in-time compiler. Supports most Python
-code natively, including C extensions.")
+programming language employing a just-in-time compiler. It supports most
+Python code natively, including C extensions.")
(license (list license:expat ; pypy itself; _pytest/
license:psfl ; python standard library in lib-python/
license:asl2.0 ; dotviewer/font/ and some of lib-python/
--- End Message ---