[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