search

jaraco / jaraco.clipboard

MIT License
19 stars 1 forks source link

New Installation Through PIP Ignores Existing Installation Path Env Variables #8

Closed Sn3akyP3t3 closed 3 years ago

Sn3akyP3t3 commented 4 years ago

I'm not exactly sure how PIP knows where Python is installed, but I suspect it could be using Environment Variables. If that's not true then my description is incorrect, but regardless PIP is pushing the install to C:\Users\Me\AppData\Roaming\Python\Python38 which on my PC prior to this didn't exist instead of C:\Program Files\Python38.

So if you setup Python using the Only Me option you will be ok with this behavior, but if you do the extra effort to install for all, which I guess you could say is legacy behavior, then you will be able to recreate this issue.

This is what PIP has to say about this during install:

Installing collected packages: more-itertools, jaraco.functools, jaraco.text, jaraco.classes, jaraco.collections, jaraco.structures, jaraco.ui, path, path.py, jaraco.windows, jaraco.clipboard
  WARNING: The scripts enver.exe, find-symlinks.exe, gclip.exe, mklink.exe, pclip.exe and xmouse.exe are installed in 'C:\Users\Me\AppData\Roaming\Python\Python38\Scripts' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

I'm going to try to workaround this problem and manually move the orphaned files from appdata to program files.

Sn3akyP3t3 commented 4 years ago

This seems to be only if the Python38 directory exists prior to the install. I uninstalled then manually deleted the appdata Python38 directory then re-installed without the same behavior described above. Must not be something the PIP installer is in control of or related to this package.

Sn3akyP3t3 commented 4 years ago

Hmmm, shortly after I was able to recreate it. It has to do with whether or not CMD Prompt is opened as admin or not. If not then appdata, if yes then Program Files. Perhaps this is still an issue.

jaraco commented 3 years ago

Thanks for the report. Unfortunately, the issue you're reporting is with pip and not with this project. Moreover, the behavior you describe is (most likely) working as intended. If you don't have permission to write to the Python installation for all users, pip will fall back to a user-local installation. See https://github.com/pypa/pip/issues/1668 for some context, although probably more context than you want. I just scanned the docs and I couldn't find any official guidance on what users are to expect as to when pip installs user-local or system-wide. Please consider filing an issue with pip explaining how the behavior is unexpected and what could be done to improve your expectation.