Fix find_uv_bin to find uv with system site packages

[ssbarnea]

Summary

This allows uv to find its binary when it was installed as a system package. Current implementation fails if someone creates a venv with --system-packages because the relative uv path would be different.

Fixes: #10194

Test Plan

[ssbarnea]

@charliermarsh please take a look at this and its bug. Let me know if further changes are needed as this is a blocker for addressing tox-dev/tox-uv#109 and in fact can happen easily even without tox. As soon you create a venv and install uv in it, once you try to create a new one, you may discover that you have an unusable uv package.

[zanieb]

Why ../../..? What path is this targeting?

[zanieb]

As soon you create a venv and install uv in it, once you try to create a new one, you may discover that you have an unusable uv package.

To be clear, this should not work by design

❯ uv venv one
Using CPython 3.13.1
Creating virtual environment at: one
Activate with: source one/bin/activate
❯ uv venv two
Using CPython 3.13.1
Creating virtual environment at: two
Activate with: source two/bin/activate
❯ uv pip install -p one uv
Using Python 3.13.1 environment at: one
Resolved 1 package in 181ms
Prepared 1 package in 1.12s
Installed 1 package in 7ms
 + uv==0.5.13
❯ ./one/bin/python -c "import uv; uv.find_uv_bin()"
❯ ./two/bin/python -c "import uv; uv.find_uv_bin()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import uv; uv.find_uv_bin()
    ^^^^^^^^^
ModuleNotFoundError: No module named 'uv'

Do you mean something else?

[ssbarnea]

To be clear, this should not work by design

Can you please elaborate around that? The way I read it is that you cannot make use of uv with venvs using system site packages.

uv venv --seed x1
source x1/bin/activate
pip install uv
python -m uv --version # works
uv --version # works

# case two:
uv venv --seed  --system-site-packages x2

source x2/bin/activate

pip install uv
Requirement already satisfied: uv in /Users/ssbarnea/.config/mise/installs/python/3.13.1/lib/python3.13/site-packages (0.5.18)
# ^ first problem, yes uv module is present due to system-site-packages but is not usable
# in any way, see below:

> python -m uv --version
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/ssbarnea/.config/mise/installs/python/3.13.1/lib/python3.13/site-packages/uv/__main__.py", line 47, in <module>
    _run()
    ~~~~^^
  File "/Users/ssbarnea/.config/mise/installs/python/3.13.1/lib/python3.13/site-packages/uv/__main__.py", line 27, in _run
    uv = os.fsdecode(find_uv_bin())
                     ~~~~~~~~~~~^^
  File "/Users/ssbarnea/.config/mise/installs/python/3.13.1/lib/python3.13/site-packages/uv/_find_uv.py", line 36, in find_uv_bin
    raise FileNotFoundError(path)
FileNotFoundError: /Users/ssbarnea/.local/bin/uv

# calling `uv` might give unreliable results now because clearly is not inside `x1/bin`
uv --version 

# example from my system:
❯ which -a uv
/Users/ssbarnea/.venv/bin/uv
/Users/ssbarnea/.config/mise/installs/python/3.13.1/bin/uv
/Users/ssbarnea/.config/mise/installs/python/3.12.8/bin/uv
/Users/ssbarnea/.config/mise/installs/python/3.11.11/bin/uv
/Users/ssbarnea/.config/mise/installs/python/3.10.16/bin/uv
/Users/ssbarnea/.config/mise/installs/python/3.9.21/bin/uv
/opt/homebrew/bin/uv

# expected behavior would be to use uv from within currently active venv (x1). The .venv one that is found instead is from user default

[zanieb]

Can you please elaborate around that? The way I read it is that you cannot make use of uv with venvs using system site packages.

I think using system site packages seems okay if the virtual environment has opted into it. The part I'm saying should not work "by design" is that one virtual environment should not be able to access the uv of another virtual environment.