guix-devel
[Top][All Lists]
Advanced

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

Re: [Python] pypy3 integration


From: zimoun
Subject: Re: [Python] pypy3 integration
Date: Mon, 27 Jul 2020 21:15:40 +0200

Hi,

On Mon, 27 Jul 2020 at 12:48, Ludovic Courtès <ludo@gnu.org> wrote:
> Lars-Dominik Braun <lars@6xq.net> skribis:
>
> >> pypy3 works somewhat well for me already in this regard:
> > indeed, you’re right.
> >
> > This will probably break for some packages, because python provides
> > Python 3.8 whereas pypy3 provides Python 3.6.  (They’ve always lagged
> > behind and given that we’re going towards 3.10, well…) One example are
> > packages depending on importlib.resources, which only became available
> > with Python 3.7. Unfortunately this includes the widely-used pytest (or
> > rather: its dependency python-pluggy).
> >
> > Also Python’s C ABI is not stable[1] and thus extensions compiled for 3.8
> > can fail in unpredictable ways with 3.6. And looking at python-numpy,
> > it seems they won’t even load.
>
> Also, what about .pyc files?  Does pypy create compatible .pyc files?

What do you mean by "compatible .pyc files"?

Well, the .pyc generated by CPython should be compatible with the ones
generated by Pypy, both VM targeting say Python 3.6.
But there is no necessary compatibility between .pyc of Python 3.6 and
Python 3.8, at least for CPython as Lars wrote.

CPython being the reference implementation, Pypy is always late.


> > So, does this justify creating pypy3-* packages?
>
> It probably does.  But do we want to mirror all the ‘python-’ packages,
> or just some of them?  It seems overkill to mirror all of them.

With the current situation, somehow you have to.  But...

> Perhaps we could have a package transformation option to turn a
> ‘python-build-system’ package into a pypy package?

...Yes it could be nice to be able to change the "package builder" of
the build-system.  (Obviously, without any guarantee that the build
would be correct for all combinatorial :-))
The issue is the same for emacs vs emacs-next, GCC versions (without
saying gcc vs clang ;-)), OCaml 4.07 vs OCaml 4.09 etc..
We already discussed this kind of issue when discussing "package parameters".


All the best,
simon



reply via email to

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