Preserve pip.main() in some fashion

[sernst]

I'm opening this issue on the recommendation of @dstufft to carry over a tangential discussion that arose in #5079.

While understanding that pip.main() is not officially supported and is being refactored to pip._internal.main() in the 10.0.0 release, there is definitely usage of it out there. GitHub code search won't allow for using . so this search isn't perfect:

https://github.com/search?l=Python&q=import+pip+main%28&type=Code&utf8=%E2%9C%93

but it returns ~850k hits of import pip + main( on public github projects.

An anecdotal pattern I notice from a quick look through them, is that many are installing data packages. Not surprising since there are many data environments (notebook deployments especially) that obfuscate access to the host environment. This is serving as an in-python way of managing dependencies that can be shared in such contexts.

I'm not sure if there's any interest in maintaining the pip.main() as a passthrough command execution wrapper, but that could potentially mitigate the pain of upgrading for many.

[pfmoore]

I wouldn't have any objection to reintroducing pip.main() in some form (it wouldn't be in pip 10, but could be in some future version). But I'd prefer it to be a wrapper around a subprocess call to pip, rather than simply exposing pip's internal function (as doing that has already been shown to have issues).

If someone were to create a PR for this, I think it would be a good thing to consider - but it would be something that needs discussion, and that's likely easier to do in the context of a proposed implementation, not just in the abstract.

[henryiii]

This change causes the following docker lines to fail:

docker run -it ubuntu
apt update && apt install -y python-pip
pip install pip==10.0b1
pip

Now pip (the command) is broken, since the pip script in /usr/bin is simply a wrapper for from pip import main, and pip's update can't touch that script. Only python -m pip works. If this remains in Pip 10, I'm afraid Pip 10 will be seen as "buggy" and people won't update (and I really want to require Pip 10 to get pyproject.toml).

[henryiii]

And, unrelated to my last post but related to this discussion, it's quite common for Jupyter notebooks (at least in the sciences) to check for a requirement, then install any missing requirements using from pip import main.

[pfmoore]

Now pip (the command) is broken, since the pip script in /usr/bin is simply a wrapper for from pip import main, and pip's update can't touch that script.

That script is presumably managed by the OS python-pip package. You shouldn't be using pip install --upgrade to upgrade OS packages, precisely for this reason. I understand that docker is a subtly different situation than the normal cases we see of users trying to use sudo pip install --upgrade to update the system installation of pip, but nevertheless the situation is the same - the distribution doesn't support using pip directly to upgrade the system packages, so you'd need to take this up with them.

Regarding Jupyter notebooks, which don't have access to a command prompt, we're aware that they have a specific problem. I'd suggest that using !pip install (using the Jupyter syntax to run a shell command) is better than invoking pip.main.

[pradyunsg]

#5149 is the PR for this.

[sirosen]

The decision on this appears to be "no", judging from the thread in #5149.
This issue should probably be closed.

I did toss something together which I'll shamelessly link here, in case people find it useful (or objectionable and want to yell at me):

• https://pypi.org/project/callable-pip/

[pradyunsg]

This issue should probably be closed.

Indeed.

[maxymczech]

This is so sad :'( Why do you people do this?

[lock]

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.