Virtualenv: prise en charge de Microsoft Store Python

@zooba cela ressemble à un mauvais emballage côté magasin Windows 🤔 ?

@gaborbernat Je pense que le bogue dans virtualenv, car le module venv fonctionne 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>

Pas vraiment mec. venv provisionne le venv créé avec tout ce que vous avez regroupé. Ici, l'importation de la pile réseau échoue (ce que fait virtualenv pour installer les derniers pip/setuptools). Passez un --no-download et virtualenv devrait également fonctionner.

@gaborbernat Je ne veux pas de virtualenv, mais pipenv l'utilise et n'a pas l'option de passer des arguments

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>

Cela se résume toujours à un problème d'emballage du noyau, car _socket n'est pas importable 🤔 Il faudra cependant valider cela.

@pfmoore cela semble lié au pip 🤔 mais se manifeste étrangement lorsqu'il est appelé depuis virtualenv en mettant la roue sur le chemin 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, il semble que notre nouveau virtualenv n'ait pas accès à _socket, mon mauvais 🤦‍♂

Donc, essayer d'importer _socket sur un virtualenv fraîchement créé échoue avec :

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

Tout en faisant la même chose depuis le python installé

Je n'ai jamais utilisé la distribution Store de Python. Je suggérerais de demander de l'aide à @zooba ici, car il est l'expert de cette distribution.

@JoDoX Pouvez-vous faire un test simple ? Démarrez Python et exécutez

import _socket
import socket

Cela devrait fonctionner sans erreur. Si vous obtenez une erreur, le problème vient de quelque chose dans Python, plutôt que de virtualenv (ou pip).

@pfmoore voir mon message ci-dessus. Ces commandes fonctionnent si vous le démarrez à partir du python installé. Cependant, ils échouent à partir de l'environnement virtuel python. Semble être lié d'une manière ou d'une autre au fait que les DLL ne sont accessibles que si elles sont exécutées à partir du Python installé. Une fois que vous avez copié l'exécutable, il semble perdre la possibilité d'accéder aux DLL en amont. Pas sûr étant donné que le problème est lié à virtualenv ou à l'emballage du magasin Windows.

Éditer:

La création d'un venv et la consultation du journal de démarrage montrent que les venv essaient en fait de charger le pyd à partir de l'emplacement d'origine. Il charge en fait tout à partir de l'emplacement d'origine. Inclure et Lib sont vides. Dans virtualenv, nous les copions pour l'instant.... Peut-être existe-t-il une meilleure façon de créer des venvs que ce que nous avons maintenant 🤔 Il faudra enquêter.

# 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, désolé - j'ai parcouru votre message et j'ai mal compris ce que vous disiez. Ma faute.

Je n'exclurais certainement pas que la copie de l'exécutable Python puisse causer des problèmes. Nous avons vraiment besoin de @zooba ici, car je ne connais aucune documentation de niveau développeur sur le fonctionnement de la construction du magasin, et je ne connais pas suffisamment le code pour y plonger.

Oui, vous ne pouvez pas copier l'exécutable. Une fois qu'il est en dehors du package d'application, son contexte n'est pas correctement activé par le système d'exploitation.

Vous pouvez soit créer un lien symbolique, soit copier le python.exe qui se trouve dans venv/scripts/nt . Il s'agit d'une copie spéciale du lanceur py.exe qui recherchera pyvenv.cfg pour trouver celui à lancer. (Ou si vous ne souhaitez pas utiliser ce fichier, vous pouvez en créer une autre version qui recherche vos paramètres de configuration préférés.)

Une fois qu'il est en dehors du package d'application, son contexte n'est pas correctement activé par le système d'exploitation.

Un peu hors sujet, mais pouvez-vous m'indiquer le code qui en fait le cas (et/ou les documents MS pertinents à ce sujet) ? J'aimerais mieux comprendre l'application du magasin que je ne le fais actuellement (je ne comprends pratiquement rien aux applications du MS Store pour le moment), donc je n'ai pas à continuer à vous envoyer des pings sur ce sujet ;-)

Je ne suis pas sûr que cette partie soit même documentée, et si c'est le cas, ce sera probablement au plus profond de la documentation MSIX ou peut-être dans certaines spécifications AppV si vous pouvez trouver cela (qui est l'ancienne version de la technologie d'isolation utilisée) .

Les packages sont destinés à être utilisés en tant qu'applications, principalement, ce qui signifie un point d'entrée unique (et empêche d'autres applications d'utiliser nos DLL). Nous ne pouvons donc pas LoadLibrary fichiers dans le package tant que nous n'avons pas vérifié que nous appartenons au package, et dans le cas général, la seule façon de le faire est de lancer le python.exe d'origine.

Oh, et pour être clair, ce sont toutes des restrictions délibérées du système d'exploitation. Python n'a pas choisi de faire en sorte que cela se produise, il n'y a donc pas de code dans CPython pour cela. Bien que les parties de launcher.c cachées derrière la définition VENV_REDIRECT puissent être intéressantes (et non prises en charge, détails internes ...)

Merci. J'ai fait quelques brèves recherches, et https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes semble être pertinent (bien que je n'aie pas lisez-le encore, je poste surtout ceci pour pouvoir retrouver le lien plus tard ;-))

@gaborbernat Je soupçonne que la "bonne" façon pour virtualenv de prendre en charge le magasin Python sera de copier le redirecteur à partir de venv/scripts/nt , comme l'a suggéré @zooba . Mais c'est extrêmement proche de l'idée d'utiliser venv pour créer l'environnement, que j'ai suggéré il y a quelque temps, et que vous n'aviez pas envie en raison des implications de compatibilité. Je soupçonne que ce serait encore pire si nous le faisions pour l'application Store, mais pas pour le Python "standard" avec la même version. (De plus, je ne suis pas sûr que mélanger le redirecteur avec des choses comme la coutume site.py de virtualenv fonctionnerait même).

Je suis heureux de vous aider avec le codage, mais j'aurai besoin de vos conseils sur l'approche que vous souhaitez adopter.

(Oh, et @zooba , pendant que j'ai votre attention, dans quelle mesure le magasin Python coexiste-t-il avec une installation Python "normale" ? Si je veux tester ce genre de choses, serai-je meilleur avec une machine virtuelle propre, pour éviter d'interférer avec mon installation Python principale ? Ou puis-je installer et désinstaller la boutique Python sans effets secondaires ?)

Alors j'ai donné une bonne pensée. En fin de compte, je pense qu'il est logique de changer la logique de base en:

• si possible créer le venv avec le venv fourni par stdlib, patcher stdlib créé venv pour offrir les mêmes garanties que les nôtres,
• sinon, utilisez notre propre logique.

Quelques endroits où stdlib fourni peut venv ne pas être présent :

• Python 2,
• distributions où le venv est empaqueté séparément et non installé pour le moment (comme ubuntu python3.7-venv). @pfmoore a enseigné ? Nous devrons dresser une liste des garanties que nous offrons en ce moment pour mettre cela en œuvre.

Je serais un fort +1 à ce sujet. Avec Python 2 atteignant très bientôt la fin de vie, nous allons être dans une situation où pratiquement toutes les versions prises en charge de Python ont venv (et celles qui n'en ont pas, ont toujours les mécanismes - pyvenv.cfg ). Donc, si nous pouvons éviter autant que possible les hacks que nous utilisons actuellement, ce serait une énorme victoire (et cela rendrait également la compatibilité entre virtualenv et venv un non-problème :-))

Le plus dur est de décider ce qui constitue la liste des garanties que nous offrons. Je ne suis pas sûr qu'il y en ait beaucoup - le seul difficile est le problème sys.real_prefix vs sys.base_prefix , et honnêtement, je pense que nous devrions suivre la stdlib à ce sujet dans tous les cas (avec une période de transition appropriée).

Je suis d'accord avec @pfmoore sur ce point.

Juste pour être clair, le support de Python 2 n'est pas prévu d'être abandonné au moins pour les 3 prochaines années. La nouvelle solution préférera simplement utiliser stdlib venv dans la mesure du possible et se rabattre sur la logique intégrée sinon.

Compris. Le processus existant doit rester pour que Python 2 soit pris en charge, mais si nous pouvons l'éviter là où le noyau venv est disponible, c'est très bien.

A commencé une discussion séparée dans https://github.com/pypa/virtualenv/issues/1366 👍

(Oh, et @zooba , pendant que j'ai votre attention, dans quelle mesure le magasin Python coexiste-t-il avec une installation Python "normale" ? Si je veux tester ce genre de choses, serai-je meilleur avec une machine virtuelle propre, pour éviter d'interférer avec mon installation Python principale ? Ou puis-je installer et désinstaller la boutique Python sans effets secondaires ?)

Désolé, j'ai raté ça, @pfmoore (les notifications Github n'attirent pas toujours mon attention...).

Vous pouvez installer/désinstaller le magasin Python sans effets secondaires - c'est en fait l'une de ses plus grandes fonctionnalités. (Bien qu'un inconvénient soit qu'il ne peut pas mettre à jour le registre d'utilisateurs réel, et donc PEP 514 n'est pas tout à fait suffisant, car l'écrasement des valeurs casserait le cycle d'installation/désinstallation propre.)

Je pense que nous avons parlé sur Twitter que ce ne serait pas un problème d'écrasement si par pep 514 nous utilisions une société différente (par exemple Microsoft Store) au lieu de PythonCore. Et puis nous avons juste besoin de mettre à jour py.exe pour accepter cela aussi.

utiliser venv au lieu de virtualenv résout le problème pour moi

L'ancien virtualenv ne peut pas et ne supportera pas cela. virtualenv 20, la réécriture, devrait. Nous devons valider, malheureusement AFAIK, il n'est pas possible d'ajouter le magasin python à Azure CI. @zooba pouvez-vous confirmer que c'est toujours le cas et que cela va continuer ?

Dans la première itération, nous pouvons simplement marquer que la méthode builtin/self-do ne prend pas en charge le magasin ; pour vérifier si le python est stocké pyhton @zooba a suggéré :

Vous voudrez probablement essayer d'ouvrir sys.executable pour la lecture, car je pense que c'est votre plus gros problème (ça va échouer)
Ou vous pouvez vérifier si pythonXY.dll n'est pas dans le même répertoire que sys.executable, ce qui, je pense, est une autre hypothèse que vous devrez corriger
Cela peut se produire de différentes manières (intégration, gel, construction statique) et je soupçonne que virtualenv ne fonctionnera avec aucun d'entre eux pour le moment
Bien que les anciens programmes d'installation (avant la version 3.5) puissent le placer dans le dossier système, ce qui fonctionnerait toujours, ce n'est donc pas un test parfait.

Ceci a maintenant été réalisé dans le cadre de #1502. Virtualenv marquera correctement le magasin python comme non compatible avec sa stratégie intégrée et se repliera pour déléguer la tâche au module venv du magasin python. La suite de tests du projet passe. De plus, nous allons maintenant utiliser le lien symbolique au lieu de la méthode de copie si le système d'exploitation Windows le prend en charge (nous testons cela en essayant de créer un lien symbolique dans un dossier temporaire).

La prise en charge intégrée de Microsoft Store dans virtualenv peut être effectuée dans un futur ticket ultérieur, probablement en améliorant notre classe cpython3windows pour utiliser les nouvelles techniques nécessaires à cette fin.