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? _______________________________________________ pypy-issue mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-issue
