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