Re: Packaging pypy
On Fri, Dec 23, 2011 at 1:44 PM, Stefano Rivera <stefanor@debian.org> wrote:
> 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
Hi Stefano.
Wouldn't looking always at /usr first break checkout overriding system
version? That would be very unfortunate unless this is only for the
debian-modified version.
PS. Thanks for doing that!
Cheers,
fijal
Reply to: