guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#41472] [PATCH] gnu: Add pypy3.


From: Ludovic Courtès
Subject: [bug#41472] [PATCH] gnu: Add pypy3.
Date: Fri, 29 May 2020 18:00:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi,

Lars-Dominik Braun <lars@6xq.net> skribis:

> 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`.

Yay!

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

> I guess the next step would be figuring out how to add “pypy3-foo”
> variants for our Python packages, right?

Maybe.  Is it generally applicable?  I hear that many core Python
packages require CPython, which makes it hard to migrate to a different
implementation.

>>From bdf71850523b42e9d710618d0e0d9ea9fbfe9f87 Mon Sep 17 00:00:00 2001
> From: Lars-Dominik Braun <lars@6xq.net>
> Date: Fri, 22 May 2020 16:02:26 +0200
> Subject: [PATCH] gnu: Add pypy3.
>
> * gnu/packages/python.scm (pypy3): New public variable.
> * gnu/packages/patches/pypy3-7.3.1-fix-tests.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it

[...]

> +(define-public pypy3
> +  (package
> +    (name "pypy3")
> +    ;; if you intend to upgrade this package, enable the tests and check
> +    ;; the results for anything abnormal

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?

Nitpick: please use uppercase at the beginning and period at the end.


[...]

> +       ("dash" ,dash)                   ; used as /bin/sh

I’d suggest ‘bash-minimal’ here, to be consistent with the other
packages.


[...]

> +    (home-page "https://www.pypy.org/";)
> +    (synopsis "Python 3.6 JIT")

Maybe “Python implementation with just-in-time compilation”?

> +    (description "This package provides a Python 3.6 just-in-time compiler.")

Maybe remove “3.6” since it’s likely to become stale.  Bonus points if
you can expound a little bit.  :-)

Thanks!

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]