di
Support an alternative to `PIPAPI_PYTHON_LOCATION` for configuring `pip-api`?
Right now, almost all of pip-api's state revolves around calls to pip, which in turn is located by pip-api by invoking it relative to the current interpreter (in effect {sys.executable} -m pip ...).
This works well 99% of the time, but it causes problems in one of pip-audit's expected installation patterns: being installed globally (e.g. via a system packager manager), but being asked to audit activated local virtual environments.
In that case, sys.executable points to the "global" Python interpreter (which itself might be indirect, like a pyenv shim), while the pip we want to target is pointed to by the $PATH (per the virtual environment). As a result, constants like pip_api.VERSION and all invocations of pip_api._call.call correspond to the "global" pip, not the one that the user might expect.
The PIPAPI_PYTHON_LOCATION environment variable notionally provides support for this, but using it correctly is not ergonomic: it needs to be set before pip_api is ever imported in order to affect constants like pip_api.VERSION.
I'm filing this mostly to think about it, since I'm not sure there's a "good" solution on pip-api's side 😅 -- the current behavior is arguably more correct since it aligns the installed pip_api package with whatever pip installed it, rather than whatever pip happens to have the highest priority in the $PATH.
Refs: https://github.com/pypa/pip-audit/issues/450, https://github.com/pypa/pip-audit/issues/455
