[davrens101]

Fixes #14055.

spacy.cli.download._get_pip_install_cmd() falls back to ["uv", "pip", "install"] when pip isn't importable (e.g. a uv venv-created environment). That command doesn't say which interpreter to install into, so uv has to discover an environment. When the venv isn't activated (VIRTUAL_ENV unset) and the working directory isn't the venv's parent, uv exits with:

error: No virtual environment found; run `uv venv` to create an environment, or pass `--system` to install into a non-virtual environment

and spacy download fails even though the interpreter running spaCy is the obvious target. The pip branch already targets it via sys.executable.

This adds --python sys.executable to the uv fallback.

Reproduced with uv 0.13.7 from a directory with no .venv and VIRTUAL_ENV unset:

Before:

$ uv pip install --dry-run wasabi
error: No virtual environment found; run `uv venv` to create an environment, or pass `--system` to install into a non-virtual environment

After (command spaCy now builds):

$ uv pip install --dry-run --python /path/to/venv/Scripts/python.exe wasabi
Using Python 3.12.10 environment at: /path/to/venv
Checked 1 package in 215ms
Would make no changes

Added a unit test in spacy/tests/test_cli.py for the constructed command; it fails before this change and passes after. pytest spacy/tests/test_cli.py -k download passes.

Checklist

• I have submitted the spaCy Contributor Agreement.
• I ran the tests, and all new and existing tests passed.
• My changes don't affect the spacy CLI.

[davrens101]

Closing as a duplicate of #14064, which already implements the same --python sys.executable fix for #14055. My dupe check raced; sorry for the noise.