Sorry, maybe I came off too strong with this. There’s really not been such a discussion - most of the conversation happened in Ship pip as a standalone application · Issue #11243 · pypa/pip · GitHub, which built off some comments in a previous PR, which are rooted in a long-term feeling that there’s no real need for pip to be so closely tied to the target environment. So this is more of an ongoing goal which we’ve recently discovered is more practical right now than we thought.
What I was trying (badly) to say was simply that we’re not looking for votes here - we won’t make a decision based on popularity, and we’re not planning on taking away the old version, so people won’t be forced to change anything if they don’t want to.
To give an example of the sort of impact we’re interested in, Jupyter has (I believe) a %pip magic command, that installs packages into the running notebook. I presume it does this by running pip in a subprocess, but I don’t know how you tell it to find the right “pip” command. If it simply assumes that pip is installed in the notebook environment, and runs “python -m pip”, then that will no longer work if pip is installed standalone, and the notebook environment was created without pip. That’s equally possible now, but much less likely, so it may be that Jupyter has a solution already, or it may be that they discount that possibility. There are many ways to address this:
- Ask users to install pip in any environment where they want to use
%pip(but will this work for hosted environments?) - Simply don’t support
%pipin environments without pip. - Download and install the pip zipapp on first use of
%pip. - Add a config option to allow the user to specify how to invoke pip.
- Look in “obvious” places (
python -m pip, a standalonepiporpip.pyzcommand onPATH) and use the first one found, or report an error if none exist. - Probably others.
I don’t know which of these are reasonable for Jupyter, or even if this is even likely to be an issue for them at all. Hence the request for feedback.