wolfgang kuehn added the comment:
I can confirm that setting __PYVENV_LAUNCHER__ to ANY path with prefix
./venv/Scripts/ does indeed mark the python session as being a virtual
environment, no special permissions needed.
However, you will have no tooling support whatsoever (e.g. PyCharms
wolfgang kuehn added the comment:
Currently we have a glitch in our internal access rights system. This resulted
in me loosing my Admin-privileges.
I can only install python from the app-store, which is ok.
But without venv support I am stuck for the time being
wolfgang kuehn added the comment:
symlinks do not work for me, this may be another bug (should I create a new
issue?):
python -m venv --without-pip --symlinks venv
Unable to symlink
'C:\\Users\\\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.P
Change by wolfgang kuehn :
--
title: Cannot use virtual environment on Windows 10 in cooperate security
settingss -> Cannot use virtual environment on Windows 10 in cooperate security
settings
type: -> behavior
___
Python tracker
New submission from wolfgang kuehn :
I just installed Python3.10.1 from the Windows 10 App Store.
Most workflows depend on creating virtual environments, but (1)
python -m venv venv
# -> Error 1260: Windows cannot open this program because it has been
prevented by a softw
wolfgang kuehn added the comment:
The second alternative (wrapping the OS handle in a file descriptor) works like
a charm, and is the less invasive workaround code-wise.
Thanks for the magic, which I must respect as such :-)
Still I feel that this is a bug since (a) it shows an unexpected
New submission from wolfgang kuehn :
On Windows, if you pass an existing file object in append mode to a subprocess,
the subprocess does **not** really append to the file:
1. A file object with `Hello World` content is passed to the subprocess
2. The content is erased
3. The subprocess writes
