Re: Future of PyPy (not PyPy3) in Debian
Hi Sandro (2020.06.05_00:00:30_+0000)
> I'm now wondering: what should we do with the entire pypy ecosystem?
Big picture:
Upstream is continuing to support pypy (2.7) for the foreseeable future.
I don't know what that will look like for stdlib support. But they need
a 2.7 interpreter for the rpython toolchain, so they're forced to
support it. They're starting to talk about porting rpython to python 3.
But that's probably a few years away, at least.
I need a 2.7 to build pypy3 (rpython). That could be cpython or pypy.
Currently both, pypy for the archs it has JIT support for, cpython for
the rest and bootstrapping new archs. My ideal would be to continue like
that.
As long as pypy is in the archive, I'd like it to be supported by
virtualenv, so that it's also useful to users.
> should we treat pypy-* packages like python-* ones and remove then as
> part of py2removal?
Generally speaking those pypy- libraries aren't needed. It looks like we
have only one app in the archive depending on them.
If upstreams drop Python 2.7 compatibility, these will have to go, anyway.
> do we need/want to track this effort with the same usertag?
You can probably get away with the same usertag. There are far fewer of
them.
> is there a (even if only hypothetical for now) programmed transition
> from pypy- to pypy3-?
pypy3 uses /usr/lib/python3/dist-packages/ so there aren't pypy3-
packages (except for ones built by src:pypy3), just python3- packages.
That works well enough for pure Python, but there's no way to express
dependencies for C extensions, usefully. I guess we may end up with some
pypy3- packages for that (although that won't completely solve the
problem). Not a problem we've faced, yet.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Reply to: