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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4657742.jUPb67b98q@kitterma-e6430
