Preserve directory-level standalone build symlinks

[charliermarsh]

Summary

This PR improves our "don't fully resolve symlinks" behavior for python-build-standalone builds based on learnings from astral-sh/python-build-standalone#380 (comment).

Specifically, we can now robustly detect whether a target executable will lead to a valid prefix or not, and iteratively resolve symlinks until we find a valid target executable.

Test Plan

Direct symlink to python

Correctly resolves to the symlink target, rather than the symlink itself.

❯ ln -s /Users/crmarsh/.local/share/uv/python/cpython-3.12.6-macos-aarch64-none/bin/python foo
❯ cargo run venv --python ./foo
❯ cat .venv/pyvenv.cfg
home = /Users/crmarsh/.local/share/uv/python/cpython-3.12.6-macos-aarch64-none/bin
implementation = CPython
uv = 0.5.7
version_info = 3.12.6
include-system-site-packages = false
prompt = uv
❯ .venv/bin/python -c "import sys"

Symlink to the Python installation

Correctly does not resolve the symlink.

❯ ln -s /Users/crmarsh/.local/share/uv/python/cpython-3.12.6-macos-aarch64-none bar
❯ cargo run venv --python ./bar
❯ cat .venv/pyvenv.cfg
home = /Users/crmarsh/workspace/uv/bar/bin
implementation = CPython
uv = 0.5.7
version_info = 3.12.6
include-system-site-packages = false
prompt = uv
❯ .venv/bin/python -c "import sys"

Direct symlink to python in a symlinked Python installation

Correctly resolves the direct symlink, but not the symlink of the Python installation.

❯ ln -s bar/bin/python baz
❯ cargo run venv --python ./baz
❯ cat .venv/pyvenv.cfg
home = /Users/crmarsh/workspace/uv/bar/bin
implementation = CPython
uv = 0.5.7
version_info = 3.12.6
include-system-site-packages = false
prompt = uv
❯ .venv/bin/python -c "import sys"

[charliermarsh]

This is pretty handy because... symlinking the full directory is much more common, and useful?

[charliermarsh]

Based on what I've learned here, I think the right thing to do would be: check if we can find STDLIB_LANDMARKS in any parent directory of the executable. If not, then we should iteratively resolve it until we find the first resolved symlink that does have STDLIB_LANDMARKS. This would make it a non-issue!

[charliermarsh]

(I think I'll try rewriting to use the logic I mentioned above, since it will also work in more nuanced cases, like a direct symlink to a Python executable that's a symlink to a Python installation.)

[zanieb]

Is it still correct to only gate this to standalone interpreters?

[charliermarsh]

It's possible that this would be equally applicable to other interpreters, but I'm a little more hesitant... The else behavior matches the standard library, and we're just less familiar with how those "other interpreters" behave.

[zanieb]

Okay. Fine with me, this logic seems very "correct" though.