Re: Packaging pypy
Hi debian-python (2011.12.23_13:44:44_+0200) ... 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 Spent a morning on it, and it seems to be working nicely now. Test failures are almost all dealt with (on x86, haven't built anywhere else, since I started). Here's a hacked virtualenv that'll work with it (upstream virtualenv doesn't expect pypy to use this install layout): https://github.com/stefanor/virtualenv/tree/pypy Please play with it, if you are interested. Or even better, review the patches. I'm sure there are some lovely bugs waiting to be found :) I ran the twisted test suite under it, and get 11 failures, compared to 8 with upstream's pypy 1.7 build. The package name and directory is unversioned. I did that because it uses PEP3147, and so packages using it shouldn't need to be rebuilt unless they build C extensions. (And hopefully there'll only be a few of those, cpyext is still rather incomplete). Does anyone think I should have versioned it? There are some debs here: http://people.debian.org/~stefanor/pypy/ (although they aren't from the cleanest build ever) I've kicked off clean amd64 and i386 builds, and will upload the results, when they are complete. 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/20120107144255.gu18...@bach.rivera.co.za
Re: Packaging pypy
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/2011122311.gj18...@bach.rivera.co.za
Re: Packaging pypy
On 11/28/2011 09:25 PM, Stefano Rivera wrote: Of course, it would have to be packaged as a separate Python stack, again. Although it would be interesting to allow modules to be built for alternate Python implementations, but that's not a trivial project... 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? -- 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/4ed4ce3e.1070...@debian.org
Re: Packaging pypy
On 11/29/2011 09:56 AM, Maciej Fijalkowski wrote: For what is worth, the .py files (but not the .pyc files) can be shared among pypy and cpython. IMO, patching pypy to lookup e.g. .pycp files before .pyc files would be appropriate for Debian (already doing something like this for .so files in 2.x). Not sure if backporting pep 3147 would be worth it. However some packages have different installation process for pypy and not pypy build (for example building optional C extensions or not). that should be handled in the packaging. Matthias -- 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/4ed4dbf6.2070...@debian.org
Re: Packaging pypy
I suppose it's not really that much work, but that would mean waiting for another pypy release (which is probably 2-3 months away) The package may include a patch to enable that specifically, if necessary. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/plus http://niemeyer.net/twitter http://niemeyer.net/blog -- I'm not absolutely sure of anything. -- 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/canysw1mu905q7yoc39v+l9qq-yaqktb_fveig97pm4syrnq...@mail.gmail.com
Re: Packaging pypy
Sorry, _actually_ CCd now. On Mon, Nov 28, 2011 at 14:54, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: Hello Ubuntu/Debian Pythoneers, Maciej (CCd) contacted me last week to figure how to get pypy officially onto Ubuntu. Being the newbie Debian/Ubuntu developer that I am, I have no idea either, so I contacted the internal company mailing list, that finally guided me towards this forum as the right place to get it packaged onto Ubuntu. I'm sure there are a lot of details to smooth things out in that integration, but it feels like a superb opportunity that we have Maciej (a pypy upstream) interested in getting things integrated. There's already a pypy PPA in Launchpad being maintained, that may serve as good way to bootstrap the work: https://launchpad.net/~pypy/+archive/ppa Would someone here be able to give a hand to Maciej on pushing that integration forward? I'm not sure how much I can help, but I'd be woohaying at the side of the field at least. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/plus http://niemeyer.net/twitter http://niemeyer.net/blog -- I'm not absolutely sure of anything. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/plus http://niemeyer.net/twitter http://niemeyer.net/blog -- I'm not absolutely sure of anything. -- 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/canysw1mpedo7oaynm6fpgkq4foqmztjm6k8kincy39h0eai...@mail.gmail.com
