Stop shipping command line wrappers for pip
pfmoore opened this issue · 4 comments
What's the problem this feature will solve?
Since the internal reorg introduced in pip 10, users (particularly on Linux) have been having problems because PATH issues mean that they end up using a pip wrapper that doesn't match the version of pip that the Python interpreter that ends up running pip uses.
There are a number of pip issues around bad interactions between pip and system command line wrappers - see #5495 as an example.
Describe the solution you'd like
Pip should stop shipping command line wrappers, and should document python -m pip as the officially supported means of running pip.
The pip command should be left to OS distribution vendors to supply and manage, if they feel that users still want a pip command. Individual users can write their own scripts and/or aliases if they want to.
We already recommend subprocess.run([sys.executable, '-m', 'pip', ...]) as the way to call pip from your program. This is just the command line equivalent of that.
Alternative Solutions
We can continue to advise users on how to fix mismatches, and ask them to raise issues with their OS/distribution vendors where possible.
Additional context
In all honesty, I suspect that we won't be able to do this. It's a big change to user experience, and it's not backward compatible. But even if we don't do this, I think it would be good to have the discussion, and to record it in a single place for future reference.
Oh wow, yes I'd forgotten that. Want me to close this as a dupe?
I'm not actually sure what the next steps would be on #3164. There seems to be a chicken and egg situation between someone (pypa?) writing a pip-cli package and us no longer shipping the wrappers. Also you were arguing that we need to retain pip install in a virtualenv, and I'm not sure how that would work (ship pip-cli bundled with virtualenv?)
@pfmoore Yea, I think that makes sense, maybe reference or quote your post here as additional information. WRT next steps... I'm not actually sure either! Certainly if we decide we need to keep it inside of a virtualenv, I'd probably just say we need to start shipping pip-cli bundled with virtualenv but I haven't sat down and really figured out the best way to migrate to that sort of layout.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.