[pypy-issue] Issue #1922: Future-proofing virtualenv (pypy/pypy)

Armin Rigo issues-reply at bitbucket.org
Sat Nov 8 13:17:54 CET 2014


New issue 1922: Future-proofing virtualenv
https://bitbucket.org/pypy/pypy/issue/1922/future-proofing-virtualenv

Armin Rigo:

Virtualenv is broken again now that we generate a separate `libpypy-c.so` file, because it doesn't copy this separate file.  Looking at the source code of virtualenv, I notice too that the list of `.dll` files to copy on Windows is hard-coded.  I would instead try to find a more future-proof way to solve it.

One such way would be to write extra logic in the `pypy` or `pypy.exe` executable: it would not be linked with `libpypy-c.so`, but locate it dynamically, if possible from the original path.  This original path happens to be written to `../lib-python/2.7/orig-prefix.txt` by virtualenv.  Alternatively, it could notice that `libpypy-c.so` is not found in the current directory, and copy it (or hard-link it) the first time from the path written in `orig-prefix.txt`.  The same can be done on Windows for the other DLLs it depends on.

Does it sound like a good idea, or just nonsense?




More information about the pypy-issue mailing list