Re: Bits from the Debian PyCon Hangout - PyPy
On Wednesday, April 15, 2015 04:54:45 PM Stefano Rivera wrote:
> 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
Since these pypy extension packages are new and there are no applications, I
think it would make a lot of sense to limit this to PY3. It makes things much
simpler technically. We should not recreate the symlink farm we used to have
for python.
I would think that all the reasons we decided separate binaries were a good
idea for python2/3 would also apply to pypy.
Scott K
Reply to: