Acontece que python -m pip "funciona", porém instala pacotes no virtualenv original.

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

É o venv ativo, deve conter 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

Mas o tox está instalado no virtualenv original

(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

Tentei criar um venv semelhante com a opção --copies , mas não teve efeito.

Acessando aqui também: https://github.com/pre-commit/pre-commit/issues/755

Suspeito que uma correção seja necessária do lado venv para fazer a dança .real_prefix . Vou investigar essa abordagem como uma solução alternativa para o bem de pre-commit

Este parece ser o problema do bpo: https://bugs.python.org/issue30811

Eu suspeito que uma correção é necessária do lado do venv para fazer a dança .real_prefix

Não está claro para mim quem deve ser o responsável pela correção. venv detectar que está sendo executado de dentro de virtualenv ou virtualenv criar um ambiente compatível com venv ? Por um lado, virtualenv é anterior a venv . Por outro lado, venv faz parte da biblioteca padrão.

Independentemente disso, aqui está a solução alternativa que tenho atualmente em tox-venv:

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

A detecção do caminho do executável pode ser melhorada, já que atualmente procura apenas python3 . por exemplo, você pode querer python3.6 , mas python3 aponta para python3.4 .

Optei por uma solução alternativa semelhante: https://github.com/pre-commit/pre-commit/blob/805a2921ad0d34698433972c6fcb1a6dca47191d/pre_commit/languages/python_venv.py#L13 -L39

(a principal diferença é que o pré-commit já faz alguma normalização, então eu uso bin/$(basename exe) vez de apenas bin/python3 )

Eh, sim, no geral, acho que devemos ser compatíveis com o venv.

@gaborbernat De acordo com berdario / pew # 173, não parece ser o caso. @uranusjr Quer se intrometer ?

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Basta adicionar um comentário se quiser mantê-lo aberto. Obrigado por suas contribuições.

1343

@gaborbernat Acho que o problema deve ser renomeado para “executando venv dentro do virtualenv” para diferenciá-lo de # 1339.

@FranklinYu o título atualizado é suficiente?

Isso está se tornando obsoleto com o # 1366 agora em pleno andamento.