-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
automatically handle the need for reinstall-all
#1442
Comments
On MacOS, I usually |
Helpful how? I try to avoid homebrew python, so it's not directly relevant; I also don't see how it addresses the issue for anyone else. |
Sorry for the misunderdstanding, but actually, I did not encounter any inconvenienve due to the homebrew Python. There is a standalone Python interpreter project and pipx has already integrated with it. If you have any concern about the Python version change of the operation system, maybe you can try with the standalone Python interpreter. IMO, the Python version change is not a specific problem for pipx, all projects and applications that leverage virtual environment will have the similar problem. Since the change happens not so frequently, I would not suggest to bring the complex logic into pipx. |
Frequency is not the issue. PIpx is recommended for users in a lot of different environments. I know what to do when the python version changes, but the error message that you get after the python version upgrade (which may be an operating system upgrade) has nothing to do with pipx, and makes it look like pipx just broke: https://mastodon.social/deck/@mcc/112560363094906967 |
I totally understand, I am not arguing this is OK but trying to provide a solution to release your concern. Standalone Python Interpreter should solve the problem completely I think. Moreover, pipx also provide management of those interpreters via |
I think you have misunderstood my concern. I know how to fix this state myself, and I don't mind fixing it. My concern is for users that do not know that they might need a standalone interpreter; they've done something like (Also, the interpreter installation doesn't seem to work for me anyway, I just get |
Thanks for the clarification, I totoally agree pipx should give more user friendly error when the application is broken.
The example in the PR might be outdated. You can try with
It is listed in the examples, but we may need more documentation to describe how it works. |
How would this feature be useful?
The most common situation for pipx troubleshooting, as the docs suggest, is when your system Python version is upgraded and nothing installed with pipx works any more.
It seems like the stubs could perform a pretty cheap check on startup to make sure the underlying venv isn't broken, and perform a reinstall if it is.
Describe the solution you'd like
In some cases (on macOS, it seems?) the Python version number is present in the absolute path to the interpreter, so that would be one thing to notice. But in a more generalized case, pipx could remember the file size and mtime of the interpreter file and bake them in to the generated stub. If that changed, a more invasive check that actually runs the interpreter and establishes platform tags could be performed, potentially re-installing before running if necessary.
Describe alternatives you've considered
Alternately, there could be some kind of hook to do this at shell startup, or user login, but I can't figure out how to make that seamless. Doing it for all environments on
pipx
invocation seems likely to be quite slow if you have a lot of environments. So this is the main thing I could think of that would allow users to skip the manual step without adding elaborate dependencies on the host platform.The text was updated successfully, but these errors were encountered: