Once @layday reviews, this is good to merge, and we can have a quick patch release.

What happens if the outer pip is on the Python path? _has_dependency respects PYTHONPATH.

This will always be the case e.g. in a Nix dev shell.

As long as its path gets resolved correctly, shouldn't it be fine? You don't been PYTHONPATH set to call pip.

You do if pip itself is on PYTHONPATH. This is with Nix:

$ echo $PYTHONPATH
/nix/store/dfkim8vahgdqhk1lrxz1j4mcighlrk99-python3-3.14.3/lib/python3.14/site-packages:/nix/store/yic25g8alpkdjyfkbim9741cpnj8yin8-python3.14-pip-25.3/lib/python3.14/site-packages
$ python -m pip -V
pip 25.3 from /nix/store/yic25g8alpkdjyfkbim9741cpnj8yin8-python3.14-pip-25.3/lib/python3.14/site-packages/pip (python 3.14)
$ PYTHONPATH= python -m pip -V
/nix/store/dfkim8vahgdqhk1lrxz1j4mcighlrk99-python3-3.14.3/bin/python: No module named pip

_PipBackend._has_valid_outer_pip will be true but when you try to run it it won't be there.

Ahh, we do use python -m pip, you are correct.

Should we just revert the PYTHONPATH changes in the last release?

Or we could disable PYTHONPATH when looking for pip. But it looks like we use importlib.metadata.distributions, so that not be easy.

We could also just refuse to look for pip if PYTHONPATH is set.

Should we just revert the PYTHONPATH changes in the last release?

Meaning #1024? It looks like it isolates the backend runner, but the linked issue (#405) is about PYTHONPATH leaking into ensurepip, which was fixed in python/cpython#92857.

Or we could disable PYTHONPATH when looking for pip.

How do we do that other than by attempting to parse and subtract PYTHONPATH from sys.path or by spawning a subprocess without PYTHONPATH and performing the dependency check there? Neither option sounds particularly appealing to me.

We could just try passing --ignore-installed to pip, but how does that interact with --python?

I've not used that before, we could try? Hopefully it's not new so we don't get bit with even more version-specific behavior. :) (Edit: looks like it's old, good)

Coverage is a bit short, but I tried something different. I tried to create a couple of tests to mimic this (with AI help), and implemented its suggestion as a fix.

For --ignore-installed, I think it's a net positive (as nothing should be there if we are making an isolated environment), but couldn't that still have issues with leakage, if something overrides or adds to the environment?

Can you be a bit more specific about --ignore-installed?

Oh, I think I was thinking about usage too, yeah, that might work. I'll make an alternate PR with that.