Re: Bits from the Debian PyCon Hangout - PyPy
Hi Scott (2015.04.15_02:17:18_+0200)
> >Consensus seems to be "give it a shot" and try to see what works.
> >There are no pypy apps, so this isn't an issue yet.
>
> What is the "it" that's to be given a shot? I see two choices there?
Give python3 + pypy3 shared dist-packages a shot.
> Did you discuss the package size implications of embedding the pypy
> extension in the python-foo binary?
There currently aren't any, so the implication would be less binary
packages, and no bloat.
The separate dist-packages was almost an accident in pypy 2. It was the
easy option, I uploaded it to exprimental, nobody really objected to it,
and it seemed to work well, so it went into unstable.
I dug in my IRC logs for the history of this, and found:
Fri May 10 2013:
09:03 < p1otr> tumbleweed: will pypy 2.0 go to unstable or experimental?
09:10 < tumbleweed> p1otr: I haven't made up my mind yet
09:11 < tumbleweed> I think my original decision was experimental until we had a way to provide modules for it
09:11 < p1otr> will dh_pypy help in making your mind? :)
09:11 < tumbleweed> you think pypy- packages are the way to go?
09:11 < tumbleweed> yes, dh_pypy would be lovely :)
09:12 < p1otr> what's the alternative to pypy-* packages? I don't think we can share python 2.X's dist-packages
09:13 < tumbleweed> share python 2.X's pyshared, with a pypy dist-packages
09:13 < tumbleweed> although, that's weird, given PEP3147 support
09:20 < tumbleweed> I'm trying to think of any advantages of separate pypy- packages, and can't
09:21 < tumbleweed> what were the arguments for python3- packages?
09:22 < p1otr> python3- and python- have different .py files (in most cases)·
09:22 < p1otr> python- and pypy- don't, but not all python- modiles work with pypy
09:22 < tumbleweed> oh, duh
09:23 < p1otr> (think: extensions, etc.)
09:23 < tumbleweed> (I don't think I got enough sleep last night)
09:23 < tumbleweed> p1otr: yes, if we used python- packages, pypy support would still have to be optional (opt-in, probably)
09:24 < p1otr> so we can either create pypy-foo packages or let dh_pypy add pypy related symlinks/maintainer scripts
09:24 < p1otr> but even then, I'd Provide: pypy-foo
09:25 < p1otr> creating a third package (-common) with .py files and python-foo/pypy-foo depending on it is probably too much
09:25 < tumbleweed> yes
09:26 < p1otr> I think pypy-foo packages are the way to go, but we should discuss that on the mailing list, I guess
09:26 < tumbleweed> we did before, inconclusively
09:26 * tumbleweed digs
09:30 < tumbleweed> http://thread.gmane.org/gmane.linux.debian.devel.python/7386/focus=7406
09:30 < tumbleweed> looks like I was in favour of pypy-
We now have a few pypy modules, and have learned a few things:
* We don't have many pypy modules (and probably don't need many - there
are no pypy apps, yet)
* Nobody is packaging C extensions (cpyext) modules for PyPy
(thankfully), but they are using CFFI.
* Adding pypy modules causes trouble in Ubuntu (pypy isn't in main), so
there is a disincentive for some people to provide them.
For pypy2, we have PEP3147 in pypy, but not cpython. So, we could share
dist-packages with cpython, say via a symlink from
/usr/lib/pypy/dist-packages/ -> /usr/lib/python2.7/dist-packages/
Some packages would be importable, others wouldn't (C extensions,
without fallback pure-python / PyPy).
Packages that required patches for pypy wouldn't work at all. But there
don't seem to be many of these in the world, generally porting is done
without forking the source.
For pypy3, we have PEP3147 in both interpreter and a standard,
cross-interpreter dist-packages path: /usr/lib/python3/dist-packages/
This isn't a particularly different situation to pypy2, except that
there's less legacy cruft (atm)
So, I'll attempt to build a pypy3 package for experimental (or
something) that uses a shared dist-packages, and add hooks to py3compile
+ py3clean. We can see what that looks like.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Reply to: