Оказывается, python -m pip "работает", однако он устанавливает пакеты в исходный virtualenv.

(outer) [vagrant@vagrant-arch ~]$ deactivate 
[vagrant@vagrant-arch ~]$ source virtualenv/bin/activate
(virtualenv) [vagrant@vagrant-arch ~]$ python -m pip install tox

Активный венв, должен содержать токс

(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/lib/python3.6/site-packages/
(virtualenv) [vagrant@vagrant-arch ~]$ ls virtualenv/bin/
activate  activate.csh  activate.fish  python  python3

Но tox устанавливается в исходный virtualenv

(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/lib/python3.6/site-packages/
__pycache__      pip                  pkg_resources  pluggy-0.5.2.dist-info  py-1.4.34.dist-info  setuptools-36.6.0.dist-info  six.py  tox-2.9.1.dist-info          virtualenv.py       wheel
easy_install.py  pip-9.0.1.dist-info  pluggy         py                      setuptools           six-1.11.0.dist-info         tox     virtualenv-15.1.0.dist-info  virtualenv_support  wheel-0.30.0.dist-info
(virtualenv) [vagrant@vagrant-arch ~]$ ls outer/bin 
activate  activate.csh  activate.fish  activate_this.py  easy_install  easy_install-3.6  pip  pip3  pip3.6  python  python-config  python3  python3.6  tox  tox-quickstart  virtualenv  wheel

Я пробовал создать аналогичный venv с опцией --copies , но это не помогло.

Нажмите и здесь: https://github.com/pre-commit/pre-commit/issues/755

Я подозреваю, что требуется исправление со стороны venv чтобы танцевать .real_prefix . Я собираюсь исследовать этот подход как обходной путь ради pre-commit

Похоже, это проблема bpo: https://bugs.python.org/issue30811

Я подозреваю, что со стороны venv требуется исправление, чтобы танцевать .real_prefix .

Мне не ясно, кто должен нести ответственность за исправление. Должен ли venv определять, что он выполняется из virtualenv , или virtualenv создавать среду, совместимую с venv ? С одной стороны, virtualenv предшествует venv . С другой стороны, venv является частью стандартной библиотеки.

Тем не менее, вот обходной путь, который у меня сейчас есть в tox-venv:

https://github.com/tox-dev/tox-venv/blob/58401663fda66dfba4f344553525c73d57432d5e/src/tox_venv/hooks.py#L10 -L49

Обнаружение пути к исполняемому файлу можно улучшить, так как в настоящее время он просто ищет python3 . например, вы можете захотеть python3.6 , но python3 указывает на python3.4 .

Я выбрал аналогичный обходной путь: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(основное отличие состоит в том, что предварительная фиксация уже выполняет некоторую нормализацию, поэтому я использую bin/$(basename exe) вместо просто bin/python3 )

Эх, да, в целом, я чувствую, что мы должны быть совместимы с Venv.

@gaborbernat Согласно berdario / pew # 173, похоже, что это не так. @uranusjr Хотите вмешаться ?

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Просто добавьте комментарий, если хотите, чтобы он оставался открытым. Спасибо за ваш вклад.

1343

@gaborbernat Я думаю, что проблему следует переименовать в «запуск venv внутри virtualenv», чтобы отличить ее от # 1339.

@FranklinYu Достаточно ли обновленного заголовка?

Это становится устаревшим с # 1366 сейчас в полном разгаре.