On Nov 13, 2017 6:47 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 14 November 2017 at 11:51, Nathaniel Smith <njs@pobox.com> wrote:
> What if instead of installing a standard entry point, the pip
> executable was installed as
>
> #!/bin/sh
> exec python -m pip "$@"
>
> on Unix-likes

It would technically be enough to make the shebang line
`#!/usr/bin/env python` so the interpreter used was picked up from the
environment, rather than being preconfigured at install time. However,
the problem is that you don't know for certain that that python will
actually have `pip` installed, so it might just fail with a cryptic
error instead.

This would still be a massive improvement over the status quo, which in this situation would present a perfect simulacrum of downloading and installing the package you asked for, except then when you start python the import still fails.

I did think of another issue: when installing into a virtualenv, we probably want to keep the current system, so explicit/path/bin/pip continues to work as expected.


However, `pip` could potentially be updated with a `checkenv`
subcommand that complains if `sys.executable` and
`shutil.which('python')` don't match (and could presumably include
other checks as well).

Unfortunately by the time you know to run this command to have already understood the problem and how to fix it :-). That said, this is probably cheap enough we could do it automatically at startup. Does pip know whether it's pip, pip3, etc. that invoked it? I guess sys.argv[0] should tell us?


> and a pip.bat with the equivalent contents on Windows?
> (Bonus: maybe this would fix the problem with upgrading pip on
> Windows?)

Depending on how the batch file was written, I think the answer to
that is "maybe":
https://stackoverflow.com/questions/2888976/how-to-make-bat-file-delete-it-self-after-completion/20333152#20333152

Sigh.

-n