The patch called "1.9-scripts-location.patch" breaks virtualenv with pypy. Virtualenv relies on $base to use the right bin folder. Reproducible: Always Steps to Reproduce: 1.Install pypy and virtualenv 2.Launch "virtualenv-2.7-pypy-2.0 test_folder" to create a new virtualenv Actual Results: An error is raised: Installing pip script to /usr/bin error: /usr/bin/pip: Permission denied Expected Results: The virtualenv is created This bug is different from bug 445822. To test virtualenv with pypy on gentoo amd64, you also need to fix 445822 before thanks to this patch: https://github.com/Kozea/virtualenv/commit/890db9b
The problem described in #445822 has been already fixed in master upstream. Regarding this issue, I can confirm the same results as the reporter. Moreover, if you revert the patch, it is possible to create a virtualenv without any problems and also install packages inside the virtualenv. However, if you re-apply the patch after you create a virtualenv, it is no longer possible to install packages with runnable scripts inside the virtualenv, with the same symptoms -- distutils tries to install the script into /usr/bin instead of <venv_dir>/bin. Steps to reproduce: 1. revert 1.9-scripts-location.patch by modifying line 90 of /usr/lib64/pypy2.0/lib-python/2.7/distutils/command/install.py 2. install a development version of virtualenv 3. virtualenv -p pypy-c2.0 test-venv 4. re-apply 1.9-scripts-location.patch by modifying line 90 of /usr/lib64/pypy2.0/lib-python/2.7/distutils/command/install.py 5. pip install sympy inside test-venv The installation fails when attempting to install isympy into /usr/bin.
Can you please try this with virtualenv 1.9.1-r1 and/or 1.10? (And possibly also with newer pypy.)
Pypy 1.9 and 2.0 (1.9-r2 and 2.0.2 for latest ebuilds) apply 1.9-scripts-location.patch, and that breaks virtualenv for with pypy, nothing changed. Note that bug 445822 is fixed in virtualenv 1.10.
*** Bug 469298 has been marked as a duplicate of this bug. ***
If we make pypy install paths similar to CPython's as suggested in bug 465546, this issue would be fixed, correct?
Created attachment 378910 [details, diff] A new scripts-location patch that fixes virtualenv issue This patch detects if smth is being installed to a prefix and uses old (unmangled) install scheme for it.
Oh, no, ignore that. It's a very well-hidden noop.
(In reply to Yuriy Taraday from comment #7) > Oh, no, ignore that. It's a very well-hidden noop. How so? Your patch did help me (pypy-bin-2.3.1 is slightly different, merged it by hand).
*** Bug 542446 has been marked as a duplicate of this bug. ***
Still having this issue. Patch still works when I remember to apply it. Anyone know why this patch hasn't been put in yet?
It really shouldn't work. I don't remember exactly why, but it should mess up things instead of fixing although it looks like it works. IIRC you'd never reach this 'if' with name == *_prefix or smth like that.
Ok, so I have a new idea. We could remove the Gentoo patch and instead pass all --install-* paths to setup.py install directly. Sadly, this may break some packages that override default paths for some fancy reason.
*** Bug 553214 has been marked as a duplicate of this bug. ***
I have committed new revisions of PyPy with a better path hack that would hopefully solve this. Long story short, now Gentoo hackery is only applied if package would normally be installed to /usr/lib*/pypy. If any other install_base is used (e.g. virtualenv), we leave the default PyPy subdirectories. Please upgrade to 2.6.0-r1 (2.6.0-r2 in pypy-bin) or 4.0.1, and test.
9998 virtualenv -p pypy -v PANDAS 9999 . PANDAS/bin/activate 10000 type pip 10001 type pypy 10002 pip install django 10003 type django-admin is fine
