Hi, On Mon, 27 Jul 2020 at 12:48, Ludovic Courtès <l...@gnu.org> wrote: > Lars-Dominik Braun <l...@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
