Virtualenv: suporte a python da loja da microsoft

@zooba isso parece uma embalagem ruim no lado da loja do Windows 🤔?

@gaborbernat Acho que bug no virtualenv, porque o módulo venv funciona bem

Microsoft Windows [Version 10.0.18908.1000]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\jodox>cd \temp\example

(.venv) C:\temp\example>python3 -m venv .venv

C:\temp\example>.\.venv\Scripts\activate.bat

(.venv) C:\temp\example>python -V
Python 3.7.3

(.venv) C:\temp\example>python -c "import sys;print(sys.executable)"
C:\temp\example\.venv\Scripts\python.exe

(.venv) C:\temp\example>python -c "import socket"

(.venv) C:\temp\example>

Não realmente cara. venv provisiona o venv criado com o que você empacota. Aqui, a importação da pilha de rede falha (o que o virtualenv faz para instalar as últimas pip/setuptools). Passe um --no-download e o virtualenv também deve funcionar.

@gaborbernat Eu não quero virtualenv, mas pipenv usa e não tem opção de passar argumentos

C:\temp\example>pipenv --help
Usage: pipenv [OPTIONS] COMMAND [ARGS]...

Options:
  --where             Output project home information.
  --venv              Output virtualenv information.
  --py                Output Python interpreter information.
  --envs              Output Environment Variable options.
  --rm                Remove the virtualenv.
  --bare              Minimal output.
  --completion        Output completion (to be eval'd).
  --man               Display manpage.
  --support           Output diagnostic information for use in GitHub issues.
  --site-packages     Enable site-packages for the virtualenv.  [env var:
                      PIPENV_SITE_PACKAGES]
  --python TEXT       Specify which version of Python virtualenv should use.
  --three / --two     Use Python 3/2 when creating virtualenv.
  --clear             Clears caches (pipenv, pip, and pip-tools).  [env var:
                      PIPENV_CLEAR]
  -v, --verbose       Verbose mode.
  --pypi-mirror TEXT  Specify a PyPI mirror.
  --version           Show the version and exit.
  -h, --help          Show this message and exit.


Usage Examples:
   Create a new project using Python 3.7, specifically:
   $ pipenv --python 3.7

   Remove project virtualenv (inferred from current directory):
   $ pipenv --rm

   Install all dependencies for a project (including dev):
   $ pipenv install --dev

   Create a lockfile containing pre-releases:
   $ pipenv lock --pre

   Show a graph of your installed dependencies:
   $ pipenv graph

   Check your installed dependencies for security vulnerabilities:
   $ pipenv check

   Install a local setup.py into your virtual environment/Pipfile:
   $ pipenv install -e .

   Use a lower-level pip command:
   $ pipenv run pip freeze

Commands:
  check      Checks for security vulnerabilities and against PEP 508 markers
             provided in Pipfile.
  clean      Uninstalls all packages not specified in Pipfile.lock.
  graph      Displays currently-installed dependency graph information.
  install    Installs provided packages and adds them to Pipfile, or (if no
             packages are given), installs all packages from Pipfile.
  lock       Generates Pipfile.lock.
  open       View a given module in your editor.
  run        Spawns a command installed into the virtualenv.
  shell      Spawns a shell within the virtualenv.
  sync       Installs all packages specified in Pipfile.lock.
  uninstall  Un-installs a provided package and removes it from Pipfile.
  update     Runs lock, then sync.


C:\temp\example>pipenv install
Creating a virtualenv for this project…
Pipfile: C:\temp\example\Pipfile
Using C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\python.exe (3.7.3) to create virtualenv…
[==  ] Creating virtual environment...Already using interpreter C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\python.exe
Using base prefix 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0'
New python executable in C:\Users\jodox\.virtualenvs\example-Q6QloNNM\Scripts\python.exe
Command C:\Users\jodox\.virt...M\Scripts\python.exe -m pip config list had error code 1
Installing setuptools, pip, wheel...

  Complete output from command C:\Users\jodox\.virt...M\Scripts\python.exe - setuptools pip wheel:
  Traceback (most recent call last):
  File "<stdin>", line 10, in <module>
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_internal\__init__.py", line 19, in <module>
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_vendor\urllib3\__init__.py", line 8, in <module>
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_vendor\urllib3\connectionpool.py", line 7, in <module>
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\socket.py", line 49, in <module>
    import _socket
ImportError: DLL load failed: Access is denied.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 13, in <module>
ImportError: cannot import name 'main' from 'pip' (C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\__init__.py)
----------------------------------------
...Installing setuptools, pip, wheel...done.

Failed creating virtual environment
[pipenv.exceptions.VirtualenvCreationException]:   File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pipenv\cli\command.py", line 254, in install
[pipenv.exceptions.VirtualenvCreationException]:       editable_packages=state.installstate.editables,
[pipenv.exceptions.VirtualenvCreationException]:   File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pipenv\core.py", line 1741, in do_install
[pipenv.exceptions.VirtualenvCreationException]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.VirtualenvCreationException]:   File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pipenv\core.py", line 574, in ensure_project
[pipenv.exceptions.VirtualenvCreationException]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.VirtualenvCreationException]:   File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pipenv\core.py", line 506, in ensure_virtualenv
[pipenv.exceptions.VirtualenvCreationException]:       python=python, site_packages=site_packages, pypi_mirror=pypi_mirror
[pipenv.exceptions.VirtualenvCreationException]:   File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\pipenv\core.py", line 935, in do_create_virtualenv
[pipenv.exceptions.VirtualenvCreationException]:       extra=[crayons.blue("{0}".format(c.err)),]
[pipenv.exceptions.VirtualenvCreationException]: Traceback (most recent call last):
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 2580, in <module>
    main()
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 831, in main
    symlink=options.symlink,
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 1123, in create_environment
    install_wheel(to_install, py_executable, search_dirs, download=download)
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 973, in install_wheel
    _install_wheel_with_search_dir(download, project_names, py_executable, search_dirs)
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 1060, in _install_wheel_with_search_dir
    call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=script)
  File "C:\Users\jodox\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv.py", line 924, in call_subprocess
    raise OSError("Command {} failed with error code {}".format(cmd_desc, proc.returncode))
OSError: Command C:\Users\jodox\.virt...M\Scripts\python.exe - setuptools pip wheel failed with error code 1

Failed to create virtual environment.

C:\temp\example>

Ainda se resume a um problema de embalagem do núcleo, pois _socket não é importável 🤔 Será necessário validar isso.

@pfmoore isso parece relacionado ao pip 🤔 mas estranhamente se manifesta quando chamado do virtualenv colocando a roda no caminho do python 👍

Command C:\Users\traveler\gi...v\Scripts\python.exe -m pip config list had error code 1
Installing setuptools, pip, wheel...

  Complete output from command C:\Users\traveler\gi...v\Scripts\python.exe - setuptools pip wheel:
  Traceback (most recent call last):
  File "<stdin>", line 10, in <module>
  File "C:\Users\traveler\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_internal\__init__.py", line 19, in <module>
  File "C:\Users\traveler\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_vendor\urllib3\__init__.py", line 8, in <module>
  File "C:\Users\traveler\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\virtualenv_support\pip-19.1.1-py2.py3-none-any.whl\pip\_vendor\urllib3\connectionpool.py", line 7, in <module>
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\socket.py", line 49, in <module>
    import _socket
ImportError: DLL load failed: Access is denied.

Edit: NM, parece que nosso novo virtualenv não tem acesso a _socket, foi mal 🤦‍♂

Portanto, tentar importar _socket em um virtualenv recém-criado falha com:

# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\_socket.cp37-win_amd64.pyd
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\_socket.pyd
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\_socket.py
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\_socket.pyw
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\Lib\_socket.pyc
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\_socket.cp37-win_amd64.pyd
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\_socket.pyd
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 670, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 583, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 1043, in create_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ImportError: DLL load failed: Access is denied.

Ao fazer o mesmo a partir do python instalado

Eu nunca usei a distribuição Store do Python. Sugiro pedir ajuda ao @zooba aqui, pois ele é o especialista nessa distribuição.

@JoDoX Você pode fazer um teste simples? Inicie o Python e execute

import _socket
import socket

Isso deve funcionar sem erros. Se você receber um erro, o problema está em algo em Python, em vez de virtualenv (ou pip).

@pfmoore veja meu post acima. Esses comandos funcionam se o iniciar a partir do python instalado. No entanto, eles falham no ambiente virtual python. Parece estar relacionado de alguma forma com o fato de que as DLLs só podem ser acessadas se executadas a partir do Python instalado. Depois de copiar o executável, parece perder a capacidade de acessar as DLLs upstream. Não tenho certeza, pois o problema está relacionado ao virtualenv ou ao empacotamento da loja do Windows.

Editar:

Criar um venv e observar o log de inicialização mostra que, de alguma forma, venvs realmente tentam carregar o pyd do local original. Na verdade, ele carrega tudo do local original. Ambos Include e Lib estão vazios. No virtualenv, copiamos isso por enquanto .... Talvez haja uma maneira melhor de criar venvs do que o que temos agora 🤔 Precisaremos investigar.

# C:\Users\traveler\git\venv\lib\encodings\__pycache__\__init__.cpython-37.pyc matches C:\Users\traveler\git\venv\lib\encodings\__init__.py
# code object from 'C:\\Users\\traveler\\git\\venv\\lib\\encodings\\__pycache__\\__init__.cpython-37.pyc'
# trying C:\Users\traveler\git\venv\lib\codecs.cp37-win_amd64.pyd
# trying C:\Users\traveler\git\venv\lib\codecs.pyd
# trying C:\Users\traveler\git\venv\lib\codecs.py
# C:\Users\traveler\git\venv\lib\__pycache__\codecs.cpython-37.pyc matches C:\Users\traveler\git\venv\lib\codecs.py
# code object from 'C:\\Users\\traveler\\git\\venv\\lib\\__pycache__\\codecs.cpython-37.pyc'

vs

# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\encodings.cp37-win_amd64.pyd
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\encodings.pyd
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\encodings.py
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\encodings.pyw
# trying C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\DLLs\encodings.pyc
# C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1008.0_x64__qbz5n2kfra8p0\lib\encodings\__pycache__\__init__.

@gaborbernat Ah, desculpe - dei uma olhada no seu post e não entendi o que você estava dizendo. Foi mal.

Eu certamente não descartaria que copiar o executável do Python pode causar problemas. Nós realmente precisamos de @zooba aqui, pois não estou ciente de nenhum documento em nível de desenvolvedor sobre como a compilação da Store funciona e não estou suficientemente familiarizado com o código para mergulhar nele.

Sim, você não pode copiar o executável. Uma vez fora do pacote do aplicativo, ele não terá seu contexto devidamente ativado pelo sistema operacional.

Você pode fazer um link simbólico ou copiar o python.exe que está em venv/scripts/nt . É uma cópia especial do iniciador py.exe que procurará pyvenv.cfg para encontrar o real a ser iniciado. (Ou se você não quiser usar esse arquivo, você pode construir outra versão dele que procure suas configurações de configuração preferidas.)

Uma vez fora do pacote do aplicativo, ele não terá seu contexto devidamente ativado pelo sistema operacional.

Um pouco offtopic, mas você pode me apontar o código que faz com que esse seja o caso (e/ou os documentos MS relevantes sobre isso)? Eu gostaria de entender o aplicativo da loja melhor do que eu entendo atualmente (basicamente não entendo nada sobre os aplicativos da MS Store no momento), então eu não tenho que ficar te perguntando sobre essas coisas ;-)

Não tenho certeza de que essa parte esteja documentada e, se estiver, provavelmente estará nos documentos do MSIX ou possivelmente em algumas especificações do AppV, se você encontrar (que é a versão mais antiga da tecnologia de isolamento usada) .

Os pacotes devem ser usados ​​principalmente como aplicativos, o que significa um único ponto de entrada (e impede que outros aplicativos usem nossas DLLs). Portanto, não podemos LoadLibrary arquivos no pacote até verificarmos que pertencemos ao pacote e, no caso geral, a única maneira de fazer isso é iniciar o python.exe original.

Ah, e para ser claro, todas essas são restrições deliberadas e próprias do sistema operacional. O Python não escolheu fazer nada disso acontecer, então não há código no CPython para isso. Embora as partes do launcher.c escondidas atrás da definição VENV_REDIRECT possam ser interessantes (e sem suporte, detalhes internos...)

Obrigado. Fiz algumas breves pesquisas e https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes parece que pode ser relevante (embora eu não tenha leia ainda, estou postando principalmente isso para que eu possa encontrar o link novamente mais tarde ;-))

@gaborbernat Suspeito que a maneira "certa" de virtualenv oferecer suporte à loja Python será copiar o redirecionador de venv/scripts/nt , como sugerido pelo @zooba . Mas isso é extremamente próximo da ideia de usar o venv para fazer a criação do ambiente, que sugeri há algum tempo, e você não gostou por causa das implicações de compatibilidade. Suspeito que seria ainda pior se fizéssemos isso para o aplicativo Store, mas não para o Python "padrão" com a mesma versão. (Além disso, não tenho certeza de que misturar o redirecionador com coisas como o site.py personalizado do virtualenv funcionaria).

Será um prazer ajudar com a codificação, mas precisarei de sua orientação sobre a abordagem que você deseja adotar.

(Ah, e @zooba , enquanto eu tenho sua atenção, quão bem a loja Python coexiste com uma instalação "normal" do Python? Se eu quiser testar essas coisas, ficarei melhor com uma VM limpa, para evitar interferir com minha instalação principal do Python? Ou posso instalar e desinstalar a loja Python sem efeitos colaterais?)

Então eu dei uma boa reflexão. No final, acho que faz sentido mudar a lógica principal para:

• se possível crie o venv com o venv fornecido pelo stdlib, faça o patch do venv criado pelo stdlib para oferecer as mesmas garantias que nós,
• caso contrário, use nossa própria lógica.

Alguns lugares onde stdlib fornecido pode venv pode não estar presente:

• python 2,
• distribuições onde o venv é empacotado separadamente e não instalado no momento (como o ubuntu python3.7-venv). @pfmoore ensinou? Precisaremos apresentar uma lista de garantias que oferecemos no momento para implementar isso.

Eu seria um forte +1 nisso. Com o Python 2 chegando ao EOL muito em breve, estaremos em uma situação em que basicamente todas as versões suportadas do Python têm venv (e aquelas que não têm, ainda têm os mecanismos - pyvenv.cfg ). Portanto, se pudermos evitar ao máximo os hacks que usamos atualmente, isso seria uma grande vitória (e também tornaria a compatibilidade entre virtualenv e venv um problema :-))

A parte difícil é decidir o que constitui a lista de garantias que oferecemos. Na verdade, não tenho certeza de que existam muitos - o único difícil é o problema sys.real_prefix vs sys.base_prefix e, honestamente, acredito que devemos seguir o stdlib sobre isso em qualquer caso (com um período de transição adequado).

Eu concordo com @pfmoore nisso.

Só para ficar claro, o suporte ao Python 2 não está planejado para ser descartado pelo menos nos próximos 3 anos. A nova solução apenas preferirá usar stdlib venv sempre que possível e, caso contrário, recorrer à lógica interna.

Entendido. O processo existente precisa permanecer para que o Python 2 seja suportado, mas se pudermos evitá-lo onde o core venv estiver disponível, ótimo.

Iniciou uma discussão separada em https://github.com/pypa/virtualenv/issues/1366 👍

(Ah, e @zooba , enquanto eu tenho sua atenção, quão bem a loja Python coexiste com uma instalação "normal" do Python? Se eu quiser testar essas coisas, ficarei melhor com uma VM limpa, para evitar interferir com minha instalação principal do Python? Ou posso instalar e desinstalar a loja Python sem efeitos colaterais?)

Desculpe, eu perdi isso, @pfmoore (notificações do Github nem sempre chamam minha atenção...).

Você pode instalar/desinstalar a loja Python sem efeitos colaterais - este é realmente um dos maiores recursos. (Embora uma desvantagem disso seja que ele não pode atualizar o registro do usuário real e, portanto, o PEP 514 não é suficiente, pois a substituição de valores interromperia o ciclo de instalação/desinstalação limpa.)

Acho que conversamos no Twitter que não seria um problema de substituição se por pep 514 usarmos uma empresa diferente (por exemplo, Microsoft Store) em vez de PythonCore. E então só precisamos atualizar o py.exe para aceitar isso também.

usar venv em vez de virtualenv resolve o problema para mim

O antigo virtualenv não pode e não suportará isso. virtualenv 20, a reescrita, deveria. Precisamos validar, infelizmente AFAIK não é possível adicionar o python da loja ao Azure CI. @zooba , você pode confirmar que esse ainda é o caso e seguirá em frente?

Na primeira iteração, podemos apenas marcar o método builtin/self-do como não suportando o armazenamento; para verificar se o python é store pyhton @zooba sugerido:

Você provavelmente quer tentar abrir sys.executable para leitura, pois acho que esse é o seu maior problema (vai falhar)
Ou você pode verificar se pythonXY.dll não está no mesmo diretório que sys.executable, o que eu acho que é outra suposição que você precisará corrigir
Isso pode acontecer de algumas maneiras diferentes (incorporação, congelamento, compilação estática) e suspeito que o virtualenv não funcionará com nenhum deles agora
Embora os instaladores antigos (pré 3.5) pudessem colocá-lo na pasta do sistema, o que ainda funcionaria, portanto, não é um teste perfeito.

Isso agora foi alcançado como parte do #1502. O Virtualenv marcará corretamente o python da loja como não compatível com sua estratégia integrada e fará o fallback para delegar a tarefa ao módulo venv do python da loja. O conjunto de testes do projeto passa. Além disso, agora usaremos o link simbólico em vez do método de cópia se o sistema operacional Windows o suportar (testamos isso tentando criar um link simbólico dentro de uma pasta temporária).

O suporte interno para a Microsoft Store no virtualenv pode ser feito em um ticket subsequente futuro, provavelmente melhorando nossa classe cpython3windows para usar as novas técnicas necessárias para isso.