-
Notifications
You must be signed in to change notification settings - Fork 410
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
Clarification regarding PEP 668? #982
Comments
See #972 |
Hi. I just found pipx. Nice project! I agree this is a problem. The PEP 668 authors have good reasons to forbid "sudo pip install" and "pip install --user", but it's harder to install pipx itself. At least I'm glad they're aware of the irony. My recommendation for users installing pipx today:
The main reason why the last step is different than @ckp95's suggestion is that I wanted to keep it simple and limit it to only 1 command. This recipe is not the ideal final state, just a pragmatic compromise for the time being. How could "pip install --user" break anything, anyway? What's the problem?Here's an example with the magic-wormhole tool and the click library. Suppose you're still using Ubuntu 18.04 (bionic). You run This is just a theoretical example because click 6.x and click 8.x are quite compatible in practice. I couldn't find any specific practical breakage for pipx and its dependencies. That is why I say the chance is very small. By the way, pipx doesn't even use click directly. Only userpath/cli.py needs it. How to install pipx in a venv, if you really want to:@ckp95 didn't write the full details. Here's what I came up with. rm -rf ~/.local/pipx/self
python3 -m venv --upgrade-deps ~/.local/pipx/self
~/.local/pipx/self/bin/pip install pipx
mkdir -p ~/.local/bin
ln -s ~/.local/pipx/self/bin/{pipx,activate-global-python-argcomplete,python-argcomplete-check-easy-install-script,register-python-argcomplete,userpath} ~/.local/bin That last line is the list of all bin scripts that would be created by pip install --user pipx. Is it OK to install pipx in a venv?I noticed that when pipx is installed in a venv, it uses a different default interpreter for the venvs it creates. E.g. Possible dirty hack to change the default interpreter: edit Maybe pipx should add some special code to I think pipx should have an install script.Not everyone is a fan of "curl | sh", but it might just be the best long term solution here. At least for Linux (and perhaps macOS). In a perfect world, the install script should also:
Well, maybe one day. Tell me what you think! |
Hi @TomiBelan, there is an approach for such an install script in #849, however lately focus has shifted to shipping a PEX file. Discussion seems to have ceased though. Your suggestions sound reasonable to me and I'm sure it would be welcomed if you overtook development!
Though, issues have been reported lately concerning distro-provided packages. |
Instead of trying to wrangle out of the restriction, I’d rather just encourage any distributions enabling |
But it must be considered that generally packages installed from the distro's package repositories receive less updates (e. g. are more likely affected by in upstream already fixed issues, or lack added features, which have been released to PyPI). There is a rather small community of downstream packagers, and the process of re-packaging/updating is costly. Which is why the release of new packages is often limited to stable/major versions. Take for example packaging in the Ubuntu package repository, or tox, which are hopelessly outdated. At least this is what I experienced with Linux systems, and consequently prefer to use |
Thanks for your comments and links! I assume pex is not relevant anymore. The discussion in #849 about pex happened before PR #895 by @dukecat0 added a pipx.pyz file built with shiv. pex and shiv are just two different tools for building a python zipapp (.pyz), right? For the pipx use case they look mostly equivalent. I do agree that installing pipx from the native distro package manager should be the primary encouraged way. My view is: "If you have root on this computer, and your Linux distro has a pipx package, and it's recent enough for you, use that." But I think the "if you don't have root, or you want the latest pipx version" use case is also important. But, if you think this will be a minority of users, and hence an install script is overkill, I can understand that. If not an install script, I suggest at least documenting this case with something like this: mkdir -p ~/.local/bin
curl -fL https://github.com/pypa/pipx/releases/latest/download/pipx.pyz -o ~/.local/bin/pipx
chmod a+x ~/.local/bin/pipx
~/.local/bin/pipx ensurepath Would you like me to send it as a documentation PR? |
A note in documentation on the pyz installation method sounds good to me. Some additional notes may be needed for environments that have |
I did more testing of pipx.pyz and I have some concerns, especially #1074. tl;dr: if you run pipx.pyz while an unrelated venv is active, the supposedly isolated venvs created by pipx.pyz can silently depend on it, and may break when the unrelated venv is deleted. Personally I think I'll avoid using pipx.pyz for now. And I won't make a docs PR to recommend it. But I could be overblowing it -- feel free to do it if you disagree. |
I’d recommend setting |
PR welcome. |
Debian has opted in adopting PEP 668. This means that they no longer allow package installations outside of virtualenvironments. References: - pypa/pipx#982 - https://peps.python.org/pep-0668/ - https://salsa.debian.org/python-team/packages/python-pip/-/blob/a1d853a6e9a0621d5cfcbf358ba6f7abebc26655/debian/NEWS
https://peps.python.org/pep-0668
Distributions may opt-in to PEP 668, to mark the system Python as externally managed. Debian already has. I think this means pipx's current Linux installation instructions won't work:
The distro I'm on right now hasn't opted in so I can't test it myself.
Furthermore, the PEP itself recommends distro maintainers include pipx in their repositories and ship it along with Python:
So I think the installation instructions should instead say that
Some people have already run into this confusion, e.g. here.
The text was updated successfully, but these errors were encountered: