Re: Packaging pypy
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
Reply to: