[pypy-dev] Change how a pypy executable finds its lib-python/lib_pypy directories?

[Armin Rigo]

Hi all,

Right now the "pypy" executable looks for its lib-python/lib_pypy
directories by starting from the path of the "pypy" executable and
going up.  That path is derived from the C-level argv[0], on which we
try once to call readlink() if it is a symlink.  That logic is in
pypy.module.sys.initpath.

When using cffi's embedding mode, however, the logic starts
differently: we start at the path of the "libpypy-c.so" library
instead, and then we look around in the same way.  This is because, of
course, there is no "pypy" executable in this case.

This difference breaks some packaged pypy's: it is the only thing that
prevents e.g. the Arch Linux pypy from working in embedded mode.  The
reason is that they install /opt/pypy/* like we recommend, and set a
symlink /usr/bin/pypy -> /opt/pypy/bin/pypy like we also recommend,
but they really move libpypy-c.so in /usr/lib/libpypy-c.so.  It works
fine in the regular case, but fails with the embedding mode.  I tried
to make a symlink /usr/lib/libpypy-c.so -> /opt/pypy/bin/libpypy-c.so
and embedding mode then works fine.

As an attempt to fix this more generally, we should make the two cases
more similar.  Does it make sense to only look around from the
"libpypy-c.so" location?  Finding the path of "libpypy-c.so" requires
a little bit more hackery than just reading "argv[0]", but on the
other hand it is not likely to break even if "pypy" is called
strangely (because argv[0] can in theory be any random string).  It is
code that is so far in pypy.module._cffi_backend.embedding, which
would probably move to pypy.module.sys.initpath.

This change would require minor fixes for pypy packagers---e.g. arch
linux would simply make a symlink for /usr/lib/libpypy-c.so instead of
for /usr/bin/pypy.  Makes sense?


A bientôt,

Armin.