I have a system-wide Python and Vapoursynth install set up on my system. Attempting to run the latest vsrepo with Vapoursynth R61 causes an error to be thrown whenever genstubs is called or updated. I've managed to trace it to two specific lines causing the issue
Line 366 in vsgenstubs4/init.py sets the target directory to wherever Vapoursynth is imported from (system-wide site-packages in this case).
Line 380 in the same file attempts to open a file in there in a+ mode (append, create if it doesn't exist) which is illegal unless you have write permissions. Which is always False for user accounts on Windows when looking at the system-wide install directory.
Running genstubs as admin does properly include plugins installed by a user. I don't know how well this holds up on systems with more than one user, and it could be a side-effect of me running cmd as admin and it inheriting part of my env.
Proposed fixes:
Check if the current invocation is a user and skip writing to VapourSynth's dist-info
Copy the dist-info to the user site-packages and modify it there
fail gracefully and warn the user
My preference would be copying the dist-info. This results in what python -m pip install -U pip does as well, as it leaves the system-wide pip alone, installs it for the user and in subsequent invocations of pip through either the python module or the script on the PATH it loads the user install due to Python's module loading preferences (user site-packages is preferred over system-wide)
I have a system-wide Python and Vapoursynth install set up on my system. Attempting to run the latest vsrepo with Vapoursynth R61 causes an error to be thrown whenever genstubs is called or updated. I've managed to trace it to two specific lines causing the issue
a+mode (append, create if it doesn't exist) which is illegal unless you have write permissions. Which is always False for user accounts on Windows when looking at the system-wide install directory.Running genstubs as admin does properly include plugins installed by a user. I don't know how well this holds up on systems with more than one user, and it could be a side-effect of me running cmd as admin and it inheriting part of my env.
Proposed fixes:
My preference would be copying the dist-info. This results in what
python -m pip install -U pipdoes as well, as it leaves the system-wide pip alone, installs it for the user and in subsequent invocations of pip through either the python module or the script on the PATH it loads the user install due to Python's module loading preferences (user site-packages is preferred over system-wide)