Skip to content
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

Open
glyph opened this issue Jun 5, 2024 · 7 comments
Open

automatically handle the need for reinstall-all #1442

glyph opened this issue Jun 5, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@glyph
Copy link

glyph commented Jun 5, 2024

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.

@huxuan
Copy link
Contributor

huxuan commented Jun 5, 2024

On MacOS, I usually export PIPX_DEFAULT_PYTHON=$(brew --prefix python)/libexec/bin/python in my .bashrc, will this be helpful for your cases?

@glyph
Copy link
Author

glyph commented Jun 5, 2024

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.

@huxuan
Copy link
Contributor

huxuan commented Jun 6, 2024

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.

@glyph
Copy link
Author

glyph commented Jun 6, 2024

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

@huxuan
Copy link
Contributor

huxuan commented Jun 6, 2024

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 pipx interpreter.

@glyph
Copy link
Author

glyph commented Jun 6, 2024

I totally understand, I am not arguing this is OK but trying to provide a solution to release your concern

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 apt install pipx; pipx install cowsay and then upgraded their operating system. This results in a broken installation with nonsensical error messages that are ambiguous and hard to search for, and the fact that they could have done something different previously doesn't really help if they're stuck in that state.

(Also, the interpreter installation doesn't seem to work for me anyway, I just get ⚠️ No executable for the provided Python version 'python3.9' found in PATH. Please make sure the provided version is on your PATH or the file path is valid. from the cowsay example given in the PR.)

@huxuan
Copy link
Contributor

huxuan commented Jun 6, 2024

My concern is for users that do not know that they might need a standalone interpreter

Thanks for the clarification, I totoally agree pipx should give more user friendly error when the application is broken.

the interpreter installation doesn't seem to work for me anyway

The example in the PR might be outdated. You can try with

$ pipx install --fetch-missing-python --python 3.11 pycowsay
  installed package pycowsay 0.0.0.2, installed using Python 3.11.9 (standalone)
  These apps are now globally available
    - pycowsay
  These manual pages are now globally available
    - man6/pycowsay.6
done! ✨ 🌟 ✨
$ pipx interpreter list
Standalone interpreters are in /usr/local/pipx/py
Python 3.11
    Used in:
     - pycowsay 0.0.0.2

It is listed in the examples, but we may need more documentation to describe how it works.

@chrysle chrysle added the enhancement New feature or request label Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants