Virtualenv: Microsoft Store Python-Unterstützung

@zooba das fühlt sich an wie eine schlechte Verpackung im Windows Store 🤔?

@gaborbernat Ich denke, Fehler in virtualenv, weil das venv-Modul gut funktioniert

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>

Nicht wirklich Mann. venv stellt das erstellte venv mit allem bereit, was Sie gebündelt haben. Hier schlägt das Importieren des Netzwerkstapels fehl (was virtualenv tut, um die neuesten pip/setuptools zu installieren). Übergeben Sie ein --no-download und virtualenv sollte auch funktionieren.

@gaborbernat Ich möchte kein virtualenv, aber pipenv verwende es und habe keine Option zum Übergeben von Argumenten

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>

Es läuft immer noch auf ein Verpackungsproblem des Kerns hinaus, da _socket nicht importierbar ist 🤔 Dies muss jedoch validiert werden.

@pfmoore , das scheint Pip-bezogen zu sein 🤔, manifestiert sich aber seltsamerweise, wenn es von virtualenv aus aufgerufen wird, indem das Rad auf den Python-Pfad gestellt wird 👍

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.

Bearbeiten: NM, anscheinend hat unsere neue virtuelle Umgebung keinen Zugriff auf _socket, mein schlechtes 🤦‍♂

Der Versuch, _socket in eine neu erstellte virtuelle Umgebung zu importieren, schlägt fehl mit:

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

Während Sie dasselbe mit dem installierten Python tun

Ich habe die Store-Distribution von Python noch nie verwendet. Ich würde vorschlagen, @zooba hier um Hilfe zu bitten, da er der Experte für diese Verteilung ist.

@JoDoX Kannst du einen einfachen Test machen? Starten Sie Python und führen Sie es aus

import _socket
import socket

Das sollte ohne Fehler funktionieren. Wenn Sie einen Fehler erhalten, liegt das Problem eher an etwas in Python als an virtualenv (oder pip).

@pfmoore siehe meinen Beitrag oben. Diese Befehle funktionieren, wenn sie von der installierten Python aus gestartet werden. Sie schlagen jedoch innerhalb der virtuellen Umgebung python fehl. Scheint irgendwie damit zusammenzuhängen, dass auf die DLLs nur zugegriffen werden kann, wenn sie vom installierten Python ausgeführt werden. Sobald Sie die ausführbare Datei kopieren, scheint sie die Fähigkeit zu verlieren, auf die Upstream-DLLs zuzugreifen. Ich bin mir nicht sicher, ob das Problem mit virtualenv oder der Windows Store-Verpackung zusammenhängt.

Bearbeiten:

Das Erstellen eines venv und das Betrachten des Startprotokolls zeigt, dass venv tatsächlich versuchen, die pyd vom ursprünglichen Speicherort zu laden. Es lädt tatsächlich alles vom ursprünglichen Speicherort. Sowohl Include als auch Lib sind leer. In virtualenv kopieren wir diese vorerst rüber.... Vielleicht gibt es einen besseren Weg, venvs zu erstellen als das, was wir jetzt haben 🤔 Muss untersucht werden.

# 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, sorry - ich habe deinen Beitrag überflogen und missverstanden, was du gesagt hast. Mein Fehler.

Ich würde sicherlich nicht ausschließen, dass das Kopieren der ausführbaren Python-Datei Probleme verursachen könnte. Wir brauchen hier wirklich @zooba , da mir keine Dokumentation auf Entwicklerebene darüber bekannt ist, wie der Store-Build funktioniert, und ich mit dem Code nicht ausreichend vertraut bin, um darin einzutauchen.

Ja, Sie können die ausführbare Datei nicht kopieren. Sobald es sich außerhalb des App-Pakets befindet, wird sein Kontext nicht ordnungsgemäß vom Betriebssystem aktiviert.

Sie können es entweder symbolisch verlinken oder das python.exe kopieren, das sich in venv/scripts/nt befindet. Es ist eine spezielle Kopie des py.exe-Startprogramms, das nach pyvenv.cfg sucht, um das eigentliche Startprogramm zu finden. (Oder wenn Sie diese Datei nicht verwenden möchten, können Sie eine andere Version davon erstellen, die nach Ihren bevorzugten Konfigurationseinstellungen sucht.)

Sobald es sich außerhalb des App-Pakets befindet, wird sein Kontext nicht ordnungsgemäß vom Betriebssystem aktiviert.

Etwas offtopic, aber können Sie mir den Code zeigen, der dies der Fall macht (und/oder die relevanten MS-Dokumente dazu)? Ich würde die Store-App gerne besser verstehen, als ich es derzeit tue (ich verstehe im Moment im Grunde nichts von MS Store-Apps), damit ich Sie nicht ständig auf dieses Zeug anpingen muss ;-)

Ich bin mir nicht sicher, ob dieser Teil überhaupt dokumentiert ist, und wenn ja, befindet er sich wahrscheinlich tief in den MSIX-Dokumenten oder möglicherweise in einigen AppV-Spezifikationen, wenn Sie das finden können (was die ältere Version der verwendeten Isolationstechnologie ist). .

Die Pakete sollen in erster Linie als Apps verwendet werden, was einen einzelnen Einstiegspunkt bedeutet (und verhindert, dass andere Apps unsere DLLs verwenden). Wir können also keine Dateien im Paket LoadLibrary speichern, bis wir überprüft haben, dass wir zu dem Paket gehören, und im Allgemeinen besteht die einzige Möglichkeit darin, das ursprüngliche python.exe zu starten.

Oh, und um es klar zu sagen, dies sind alles absichtliche Einschränkungen des Betriebssystems. Python hat sich nicht dafür entschieden, dies zu bewirken, daher gibt es in CPython keinen Code dafür. Obwohl die Teile von launcher.c , die hinter der VENV_REDIRECT -Definition versteckt sind, interessant sein können (und nicht unterstützte, interne Details ...)

Danke. Ich habe ein wenig gegraben, und https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes sieht so aus, als ob es relevant sein könnte (obwohl ich es nicht getan habe gelesen, ich poste das meistens, damit ich den Link später wiederfinde ;-))

@gaborbernat Ich vermute, dass der "richtige" Weg für virtualenv zur Unterstützung von Store Python darin bestehen wird, den Redirector von venv/scripts/nt zu kopieren, wie @zooba vorgeschlagen hat. Aber das kommt der Idee, venv für die Umgebungserstellung zu verwenden, sehr nahe, die ich vor einiger Zeit vorgeschlagen habe und die Ihnen wegen der Kompatibilitätsimplikationen nicht gefallen hat. Ich vermute, dass es noch schlimmer wäre, wenn wir es für die Store-Anwendung tun würden, aber nicht für das "Standard" -Python mit derselben Version. (Außerdem bin ich mir nicht sicher, ob das Mischen des Redirectors mit Dingen wie dem benutzerdefinierten site.py virtualenv überhaupt funktionieren würde).

Ich helfe gerne beim Programmieren, aber ich brauche Ihre Anleitung für den Ansatz, den Sie wählen möchten.

(Oh, und @zooba , während ich Ihre Aufmerksamkeit habe, wie gut koexistiert der Store-Python mit einer "normalen" Python-Installation? Wenn ich dieses Zeug testen möchte, bin ich besser mit einer sauberen VM, um Störungen zu vermeiden mit meiner Haupt-Python-Installation? Oder kann ich das Store-Python ohne Nebeneffekte installieren und deinstallieren?)

Also habe ich mir das gut überlegt. Am Ende halte ich es für sinnvoll, die Kernlogik umzustellen auf:

• Wenn möglich, erstellen Sie die venv mit der von stdlib bereitgestellten venv, patchen Sie die stdlib, die venv erstellt hat, um die gleichen Garantien wie unsere eigenen zu bieten.
• Verwenden Sie andernfalls unsere eigene Logik.

Einige Stellen, an denen die bereitgestellte stdlib möglicherweise venv enthält, sind möglicherweise nicht vorhanden:

• Python 2,
• Distributionen, bei denen das venv separat verpackt und derzeit nicht installiert ist (z. B. ubuntu python3.7-venv). @pfmoore gelehrt? Wir müssen eine Liste der Garantien erstellen, die wir im Moment anbieten, um dies umzusetzen.

Ich würde eine starke +1 dazu geben. Da Python 2 sehr bald EOL erreicht, werden wir in eine Situation geraten, in der im Grunde alle unterstützten Versionen von Python venv haben (und diejenigen, die dies nicht tun, haben immer noch die Mechanismen - pyvenv.cfg ). Wenn wir also die Hacks, die wir derzeit verwenden, so weit wie möglich vermeiden können, wäre das ein großer Gewinn (und es würde auch die Kompatibilität zwischen virtualenv und venv zu einem unproblematischen machen :-))

Der schwierige Teil ist die Entscheidung, was die Liste der von uns angebotenen Garantien ausmacht. Ich bin mir nicht wirklich sicher, ob es viele gibt - das einzig schwierige ist das Problem sys.real_prefix und sys.base_prefix , und ehrlich gesagt glaube ich, dass wir uns auf jeden Fall dazu bewegen sollten, der stdlib zu folgen (mit eine angemessene Übergangsfrist).

Da stimme ich @pfmoore zu.

Nur um es klarzustellen, die Python 2-Unterstützung soll zumindest für die nächsten 3 Jahre nicht eingestellt werden. Die neue Lösung wird es einfach vorziehen, stdlib venv zu verwenden, wo dies möglich ist, und ansonsten auf die integrierte Logik zurückzugreifen.

Verstanden. Der bestehende Prozess muss beibehalten werden, damit Python 2 unterstützt wird, aber wenn wir ihn vermeiden können, wo Core venv verfügbar ist , ist das großartig.

Eine separate Diskussion in https://github.com/pypa/virtualenv/issues/1366 👍 gestartet

(Oh, und @zooba , während ich Ihre Aufmerksamkeit habe, wie gut koexistiert der Store-Python mit einer "normalen" Python-Installation? Wenn ich dieses Zeug testen möchte, bin ich besser mit einer sauberen VM, um Störungen zu vermeiden mit meiner Haupt-Python-Installation? Oder kann ich das Store-Python ohne Nebeneffekte installieren und deinstallieren?)

Tut mir leid, dass ich das verpasst habe, @pfmoore (Github-Benachrichtigungen erregen nicht immer meine Aufmerksamkeit ...).

Sie können den Store Python ohne Nebeneffekte installieren/deinstallieren – das ist tatsächlich eines seiner größten Features. (Ein Nachteil davon ist jedoch, dass die echte Benutzerregistrierung nicht aktualisiert werden kann und PEP 514 daher nicht ganz ausreicht, da das Überschreiben von Werten den sauberen Installations-/Deinstallationszyklus unterbrechen würde.)

Ich glaube, wir haben über Twitter darüber gesprochen, dass es kein Problem des Überschreibens wäre, wenn wir per pep 514 ein anderes Unternehmen (z. B. Microsoft Store) anstelle von PythonCore verwenden. Und dann müssen wir nur py.exe aktualisieren, um das auch zu akzeptieren.

Die Verwendung von venv anstelle von virtualenv löst das Problem für mich

Die alte virtualenv kann und wird dies nicht unterstützen. virtualenv 20, die Neufassung, sollte. Wir müssen bestätigen, dass es leider AFAIK nicht möglich ist, die Store-Python zum Azure CI hinzuzufügen. @zooba können Sie bestätigen, dass dies immer noch der Fall ist und fortgesetzt wird?

In der ersten Iteration können wir einfach markieren, dass die eingebaute/selbsttätige Methode den Store nicht unterstützt; um zu überprüfen, ob die Python gespeichert ist, pyhton @zooba vorgeschlagen:

Sie möchten wahrscheinlich versuchen, sys.executable zum Lesen zu öffnen, da ich denke, dass dies Ihr größtes Problem ist (es wird fehlschlagen).
Oder Sie könnten überprüfen, ob sich pythonXY.dll nicht im selben Verzeichnis wie sys.executable befindet, was meiner Meinung nach eine weitere Annahme ist, die Sie beheben müssen
Das kann auf verschiedene Arten geschehen (Einbetten, Einfrieren, statischer Build) und ich vermute, dass virtualenv derzeit mit keinem von ihnen funktionieren wird
Obwohl die alten (vor 3.5) Installer es in den Systemordner legen konnten, was immer noch funktionieren würde, also kein perfekter Test.

Dies wurde nun im Rahmen von #1502 erreicht. Virtualenv markiert den Store-Python korrekt als nicht kompatibel mit seiner integrierten Strategie und dem Fallback, um die Aufgabe an das venv-Modul des Store-Pythons zu delegieren. Die Testsuite des Projekts wird bestanden. Außerdem werden wir jetzt den Symlink anstelle der Kopiermethode verwenden, wenn das Windows-Betriebssystem dies unterstützt (wir testen dies, indem wir versuchen, einen Symlink in einem temporären Ordner zu erstellen).

Die integrierte Unterstützung für den Microsoft Store in der virtuellen Umgebung kann in einem zukünftigen nachfolgenden Ticket erfolgen, wahrscheinlich durch Verbesserung unserer cpython3windows-Klasse, um die dafür erforderlichen neuen Techniken zu verwenden.