Skip to content

Stop shipping command line wrappers for pip #5508

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

Closed
pfmoore opened this issue Jun 15, 2018 · 4 comments
Closed

Stop shipping command line wrappers for pip #5508

pfmoore opened this issue Jun 15, 2018 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@pfmoore
Copy link
Member

pfmoore commented Jun 15, 2018

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.

@dstufft
Copy link
Member

dstufft commented Jun 15, 2018

I think this is basically a duplicate of #3164?

@pfmoore
Copy link
Member Author

pfmoore commented Jun 15, 2018

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?)

@dstufft
Copy link
Member

dstufft commented Jun 15, 2018

@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.

@lock
Copy link

lock bot commented Jun 2, 2019

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.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

2 participants