Hi Matthias (2011.11.29_14:21:18_+0200) > maybe for binary packages, but there is no reason why a pypy extension > couldn't > be built from the same source packages. Could you summarize why it needs to > be > a separate stack?
One question is: How broken we want to allow modules to be. If it's opt-in, then only modules that are known to work will be importable (but getting adoption from maintainers would probably be slow). I haven't tested if PyPy can successfully byte-compile all .py files (that claim 2.7 support), but that's easy enough to test. We do need separate byte-compiled files, and separate C extensions. (Also discussed elsewhere in this thread). And some packages are presumably going to install differently under PyPy (e.g. skip some C-extensions, even add some pure-python? I have no numbers on this, does anyone?) All of that makes me think that we at least need to treat it as a separate Python version. It could be added as another symlink farm for dh_python2 to manage (although probably with moderate pain, dh_python2 thinks all python versions are sequential). It doesn't necessarily have to be opt-in (although that's one way to ensure that only the things that we know work are exposed). It's plausible that some maintainers wouldn't want to deal with PyPy related failures (they know their upstream code doesn't support PyPy), so opt-out may be necessary. Maciej: Remind me: How stable is PyPy's bytecode format? Do we expect it to change for 2.x-compatible PyPy? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111129141340.ga29...@bach.rivera.co.za
