Virtualenv: soporte de python de la tienda de microsoft

@zooba esto se siente como un mal empaque en el lado de la tienda de Windows 🤔?

@gaborbernat Creo que hay un error en virtualenv, porque el módulo venv funciona bien

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>

No realmente hombre. venv aprovisiona el venv creado con lo que haya incluido. Aquí falla la importación de la pila de red (lo que hace virtualenv para instalar las últimas pip/setuptools). Pase --no-download y virtualenv también debería funcionar.

@gaborbernat No quiero virtualenv, pero pipenv lo usa y no tiene opción para pasar 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>

Todavía se reduce a un problema de empaque del núcleo, ya que _socket no es importable 🤔 Sin embargo, deberá validar esto.

@pfmoore esto parece relacionado con pip 🤔 pero extrañamente se manifiesta cuando se llama desde virtualenv poniendo la rueda en el camino de 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.

Editar: NM, parece que nuestro nuevo virtualenv no tiene acceso a _socket, mi error 🤦‍♂

Entonces, intentar importar _socket en un virtualenv recién creado falla con:

# 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.

Mientras hace lo mismo desde el python instalado

Nunca he usado la distribución Store de Python. Sugeriría pedirle ayuda a @zooba aquí, ya que él es el experto en esa distribución.

@JoDoX ¿Puedes hacer una prueba simple? Inicie Python y ejecute

import _socket
import socket

Eso debería funcionar sin errores. Si obtiene un error, entonces el problema está relacionado con algo en Python, en lugar de con virtualenv (o pip).

@pfmoore mira mi publicación anterior. Esos comandos funcionan si se inicia desde el python instalado. Sin embargo, fallan desde el entorno virtual python. Parece estar relacionado de alguna manera con el hecho de que solo se puede acceder a las DLL si se ejecutan desde Python instalado. Una vez que copia el ejecutable, parece perder la capacidad de acceder a las DLL ascendentes. No estoy seguro dado que el problema está relacionado con virtualenv o el paquete de la tienda de Windows.

Editar:

Crear un venv y mirar el registro de inicio muestra que de alguna manera los venv realmente intentan cargar el pyd desde la ubicación original. En realidad carga todo desde la ubicación original. Tanto Incluir como Lib están vacíos. En virtualenv los copiamos por ahora... Tal vez haya una mejor manera de crear venvs que la que tenemos ahora 🤔 Habrá que 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'

contra

# 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, lo siento, leí tu publicación y entendí mal lo que decías. Mi error.

Ciertamente, no descartaría que copiar el ejecutable de Python pueda causar problemas. Realmente necesitamos @zooba aquí, ya que no conozco ningún documento de nivel de desarrollador sobre cómo funciona la compilación de la Tienda, y no estoy lo suficientemente familiarizado con el código para sumergirme en él.

Sí, no puedes copiar el ejecutable. Una vez que esté fuera del paquete de la aplicación, el sistema operativo no activará correctamente su contexto.

Puede vincularlo o copiar el python.exe que está en venv/scripts/nt . Es una copia especial del iniciador py.exe que buscará pyvenv.cfg para encontrar el que se debe iniciar. (O si no desea usar ese archivo, puede crear otra versión que busque sus ajustes de configuración preferidos).

Una vez que esté fuera del paquete de la aplicación, el sistema operativo no activará correctamente su contexto.

Algo fuera de tema, pero ¿puede indicarme el código que hace que este sea el caso (y/o los documentos de MS relevantes sobre esto)? Me gustaría entender la aplicación de la tienda mejor de lo que lo hago actualmente (básicamente, no entiendo nada sobre las aplicaciones de la tienda MS en este momento), así que no tengo que seguir haciéndote un ping sobre estas cosas ;-)

No estoy seguro de que esta parte esté siquiera documentada, y si lo está, probablemente estará en lo profundo de los documentos de MSIX o posiblemente en algunas especificaciones de AppV si puede encontrar eso (que es la versión anterior de la tecnología de aislamiento utilizada) .

Los paquetes están destinados a usarse como aplicaciones, principalmente, lo que significa un único punto de entrada (y evitar que otras aplicaciones usen nuestras DLL). Por lo tanto, no podemos LoadLibrary archivos en el paquete hasta que hayamos verificado que pertenecemos al paquete y, en general, la única forma de hacerlo es iniciar el python.exe original.

Ah, y para ser claros, todas estas son restricciones de sistema operativo deliberadas y diseñadas. Python no eligió hacer que nada de esto sucediera, por lo que no hay código en CPython para ello. Aunque las partes de launcher.c ocultas detrás de la definición VENV_REDIRECT pueden ser interesantes (y detalles internos no admitidos...)

Gracias. Investigué brevemente y https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes parece que podría ser relevante (aunque no lo he hecho). léalo todavía, principalmente estoy publicando esto para poder encontrar el enlace nuevamente más tarde ;-))

@gaborbernat Sospecho que la forma "correcta" para que virtualenv admita la tienda Python será copiar el redirector de venv/scripts/nt , como sugirió @zooba . Pero eso es extremadamente cercano a la idea de usar venv para crear el entorno, que sugerí hace un tiempo, y no te gustó debido a las implicaciones de compatibilidad. Sospecho que sería aún peor si lo hiciéramos para la aplicación Store, pero no para el Python "estándar" con la misma versión. (Además, no estoy seguro de que mezclar el redirector con cosas como el site.py personalizado de virtualenv funcione).

Me complace ayudar con la codificación, pero necesitaré su orientación sobre el enfoque que desea adoptar.

(Ah, y @zooba , mientras tengo su atención, ¿qué tan bien coexiste la tienda Python con una instalación "normal" de Python? Si quiero probar esto, ¿seré mejor con una máquina virtual limpia para evitar interferir? con mi instalación principal de Python? ¿O puedo instalar y desinstalar la tienda Python sin efectos secundarios?)

Así que le di a esto un buen pensamiento. Al final, creo que tiene sentido cambiar la lógica central a:

• si es posible, cree el venv con el stdlib provisto venv, parchee el stdlib creado venv para ofrecer las mismas garantías que nosotros,
• de lo contrario, use nuestra propia lógica.

Algunos lugares donde stdlib proporcionada podría no estar presente:

• pitón 2,
• distribuciones donde el venv se empaqueta por separado y no está instalado en este momento (como ubuntu python3.7-venv). @pfmoore enseñó? Tendremos que elaborar una lista de las garantías que ofrecemos en este momento para implementar esto.

Sería un fuerte +1 en esto. Con Python 2 llegando a EOL muy pronto, estaremos en una situación en la que básicamente todas las versiones compatibles de Python tienen venv (y las que no, todavía tienen los mecanismos - pyvenv.cfg ). Entonces, si podemos evitar los hacks que usamos actualmente tanto como sea posible, sería una gran victoria (y también haría que la compatibilidad entre virtualenv y venv no sea un problema :-))

La parte difícil es decidir qué constituye la lista de garantías que ofrecemos. En realidad, no estoy seguro de que haya muchos: el único difícil es el problema sys.real_prefix frente a sys.base_prefix y, sinceramente, creo que deberíamos movernos para seguir el stdlib en esto en cualquier caso (con un período de transición adecuado).

Estoy de acuerdo con @pfmoore en esto.

Para que quede claro, no se planea eliminar el soporte de Python 2 al menos durante los próximos 3 años. La nueva solución simplemente preferirá usar stdlib venv cuando sea posible y, de lo contrario, recurrir a la lógica integrada.

Entendido. El proceso existente debe permanecer para que Python 2 sea compatible, pero si podemos evitarlo donde está disponible core venv, genial.

Comenzó una discusión separada en https://github.com/pypa/virtualenv/issues/1366 👍

(Ah, y @zooba , mientras tengo su atención, ¿qué tan bien coexiste la tienda Python con una instalación "normal" de Python? Si quiero probar esto, ¿seré mejor con una máquina virtual limpia para evitar interferir? con mi instalación principal de Python? ¿O puedo instalar y desinstalar la tienda Python sin efectos secundarios?)

Lo siento, me perdí esto, @pfmoore (las notificaciones de Github no siempre me llaman la atención...).

Puede instalar/desinstalar la tienda Python sin efectos secundarios; esta es en realidad una de sus características más importantes. (Aunque una desventaja de esto es que no puede actualizar el registro de usuario real, por lo que PEP 514 no es suficiente, ya que sobrescribir los valores interrumpiría el ciclo de instalación/desinstalación limpia).

Creo que hablamos en Twitter de que no sería un problema de sobrescritura si, según el pep 514, usamos una empresa diferente (por ejemplo, Microsoft Store) en lugar de PythonCore. Y luego solo necesitamos actualizar py.exe para aceptar eso también.

usar venv en lugar de virtualenv me resuelve el problema

El viejo virtualenv no puede y no soportará esto. virtualenv 20, la reescritura, debería. Necesitamos validar, lamentablemente AFAIK no es posible agregar la tienda python a Azure CI. @zooba , ¿puede confirmar que este sigue siendo el caso y que seguirá adelante?

En la primera iteración, podemos simplemente marcar que el método integrado/auto-hacer no es compatible con la tienda; para verificar si el python es store pyhton @zooba sugirió:

Probablemente quiera intentar abrir sys.executable para leer entonces, ya que creo que ese es su mayor problema (fallará)
O puede verificar si pythonXY.dll no está en el mismo directorio que sys.executable, que creo que es otra suposición que deberá corregir
Ese puede suceder de diferentes maneras (incrustación, congelación, construcción estática) y sospecho que virtualenv no funcionará con ninguno de ellos en este momento
Aunque los instaladores antiguos (anteriores a 3.5) podían colocarlo en la carpeta del sistema, lo que aún funcionaría, por lo que no es una prueba perfecta.

Esto ahora se ha logrado como parte de #1502. Virtualenv marcará correctamente la tienda python como no compatible con su estrategia integrada y retrocederá para delegar la tarea al módulo venv de la tienda python. El conjunto de pruebas del proyecto pasa. Además, ahora usaremos el enlace simbólico en lugar del método de copia si el sistema operativo Windows lo admite (lo probamos intentando crear un enlace simbólico dentro de una carpeta temporal).

El soporte integrado para Microsoft Store dentro de virtualenv se puede realizar en un futuro ticket posterior, probablemente mejorando nuestra clase cpython3windows para usar las nuevas técnicas necesarias para esto.