Hi debian-python (2011.11.28_22:25:18_+0200) > I'm interested in this, and happy to help.
... so, I've spent some time on this, and have an incomplete package to show for it: http://anonscm.debian.org/gitweb/?p=users/stefanor/pypy.git Got lots of family things happening atm, so haven't done anything in the last couple of days, and won't do much more in the next few, so I thought now would be a good time for a status report. Anyone feel like collaborating on the remaining issues? == High level == Imported most relevant stdlib patches from Debian's python2.7 package. (Meh, multiple copies of the stdlib is ugly, but unavoidable) Patches that I haven't imported or looked at thoroughly yet: statvfs-f_flag-constants.diff, distutils-sysconfig.diff I added PEP3147 support, largely based on Barry's initial PEP3147 patch. It seems to work, but isn't very well tested yet. I also made __file__ refer to the source file, which predated PEP3147. This may cause some things to break, needs more investigation. A few failing tests remaining. Most of the failing tests are due to my modifications, and I haven't fixed the tests yet. virtualenv is currently broken, details below. == Patches applied == The patches all have DEP3 headers, so I don't think I have to say too much here... == Packing stuff == I've got a basic working package build. The rules file isn't pretty, but it does the job... The package splits the stdlib into an architecture-independant package, which makes byte-compilation of the stdlib a little more trick, but I think I've got that working reliably. The package is xz compressed. If you can build it, you can compress it :) Copyright file is incomplete (all the stdlib modules with odd licences haven't been mentioned). PyPy includes the constants from the shared libraries it links against. I don't *think* this is a major problem (although an unnecessary space waste), but it was enough to make lintian scream blue murder. PyPy doesn't handle prefix quite the same way as cpython. It finds its standard library by looking up the directory hierarchy from its binary, with a usual install layout like this: . ├── bin │ └── pypy ├── include │ └── ... ├── lib_pypy │ └── ... ├── lib-python │ ├── 2.7 │ │ └── ... │ └── modified-2.7 │ └── ... └── site-packages You'll notice that this matches the source layout, and so pypy's sysconfig scheme allows it to run installed or from a build directory, with the same scheme. I have a hacky /usr prefix patch, and a dist-packages patch but they break virtualenv. Virtualenv attempts to run a copy of the python inside the virtualenv. It then isn't in /usr and so can't find its modules. I'm thinking a better solution here is to *always* look in /usr unless an environment variable (that we'll have set at build time, for the tests) is present. I'm building some binaries now (build takes 3 hours or so, bootstrapping from cpython), I can post a link when they are done. 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/20111223114444.gj18...@bach.rivera.co.za
