You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per observations noted in #791 and related issues, pipx breaks when you update Python (at least if you remove the old installation). As far as I could find quickly on this tracker, the only known solution was to delete the entire pipx directory in your home dir/user profile (E.g. ~/.local/pipx on Linux or %USERPROFILE%\pipx on Windows). I did that, but then pulled the deleted data out of my recycle bin to investigate where exactly the reference to the old Python installation was being stored. It seems like the problem is at least partly the file ./shared/pyvenv.cfg, particularly the home var but the version variable is also not updated.
... Although as noted below, updating this file alone did not seem to fix my problem
How to reproduce
Install a newer version of Python than the one used to install pipx
Uninstall (or temporarily rename) the old Python installation
if you renamed the old install, you may need to install pipx again if you previously installed it with pip install pipx
attempt to use pipx
Expected behavior
If the interpreter is unavailable at the expected location (and particularly if it seems to be permanently unavailable, as opposed to, for instance, residing on a disconnected network device), but a newer interpreter exists, (offer to) automatically update stuff so the new version. "Stuff" could just be the base interpreter of the virtual environment, or could also include modules. In the face of ambiguity, refuse the temptation to guess and ask the user what they want to do.
Actual behavior
I get an error that doesn't make much sense to me, since I'm not the one that told it to look for the interpreter in the depreciated directory.
The text was updated successfully, but these errors were encountered:
Seems like I still get this error if I update the venv config manually. Given how many hits I get if I search the rest of the "shared" directory for the string "311" I'm thinking maybe I am going about this wrong, since it appears in almost all the module names under pipx/shared/Lib/site-packages/
This seems like a good time for me to learn how to use the venv module to update this environment "nicely" instead of rudely rm -rfing (Or in my case, the Windows equivalent thereof)
In the meantime, I've updated the expected behavior in the issue header.
@Twisted-Code Did you try to update the path in the pipx_shared.pth file as well? It's located in ~/.local/pipx/venvs/<package_name>/lib/python3.11/site-packages/pipx_shared.pth
Describe the bug
Per observations noted in #791 and related issues, pipx breaks when you update Python (at least if you remove the old installation). As far as I could find quickly on this tracker, the only known solution was to delete the entire pipx directory in your home dir/user profile (E.g.
~/.local/pipx
on Linux or%USERPROFILE%\pipx
on Windows). I did that, but then pulled the deleted data out of my recycle bin to investigate where exactly the reference to the old Python installation was being stored. It seems like the problem is at least partly the file./shared/pyvenv.cfg
, particularly the home var but the version variable is also not updated.... Although as noted below, updating this file alone did not seem to fix my problem
How to reproduce
pip install pipx
Expected behavior
If the interpreter is unavailable at the expected location (and particularly if it seems to be permanently unavailable, as opposed to, for instance, residing on a disconnected network device), but a newer interpreter exists, (offer to) automatically update stuff so the new version. "Stuff" could just be the base interpreter of the virtual environment, or could also include modules. In the face of ambiguity, refuse the temptation to guess and ask the user what they want to do.
Actual behavior
I get an error that doesn't make much sense to me, since I'm not the one that told it to look for the interpreter in the depreciated directory.
The text was updated successfully, but these errors were encountered: