uv venv fails because python3.wrapper is not available

[csalerno-asml]

Machine: RHEL7

$ python3 -m pip install uv==0.1.7
$ uv venv
Querying Python at `/home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper` failed with status exit status: 127:
  │ --- stdout:

  │ --- stderr:
  │ /home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper: line 5: python3.wrapper: command not found
  │ ---

[konstin]

How did you install python?

[Crissal1995]

Via a proprietary enterprise tool, so some shenanigans are happening with paths.

However running python3 -m venv .venv works correctly, shouldn't uv run the same command?

[zanieb]

uv implements its own virtual environment creation in Rust, we do not call Python's virtual environment tooling.

[Crissal1995]

Isn't possible to implement a fallback in case of custom python installations?

[konstin]

Could you run with debug logging?

RUST_LOG=debug uv venv -v

For background, we rely on python -c "<our probing script>" to get information about the python interpreter (e.g. its version and its paths). Is there a reason why python -m venv works while python -c doesn't?

[csalerno-asml]

There you go:

$ RUST_LOG=debug uv venv -v
 uv_interpreter::python_query::find_default_python platform=Platform { os: Manylinux { major: 2, minor: 17 }, arch: X86_64 }, cache=Cache { root: "/home/csalerno/.cache/uv", refresh: None, _temp_dir_drop: None }
      0.016782s  11ms DEBUG uv_interpreter::interpreter Detecting markers for: /home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper
  × Querying Python at `/home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper` failed
  │ with status exit status: 127:
  │ --- stdout:

  │ --- stderr:
  │ /home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper: line 5: python3.wrapper:
  │ command not found
  │ ---

Regarding your question, not sure, maybe some enterprise rules, however python -c works fine.

$ python -c 'print("hello world")'
hello world

However in our setup, python is v2.7.14, while python3 is v3.10.5, so maybe python2 is actually called by uv?

[MichaReiser]

However in our setup, python is v2.7.14, while python3 is v3.10.5, so maybe python2 is actually called by uv?

uv calls python 2 to get its version information. But it won't use it if you have a Python3 installation.

Can you run which python and would you mind sharing the content of cat /home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper (assuming it contains no sensitive content)? I wonder if it fails because we canonicalize the path

[csalerno-asml]

Sure, no sensitive content found :)

which python

/home/csalerno/.caddir/RHEL7/cadbin/python

cat /home/cadappl_RHEL7/python3/3.10.5/wrapper/python3.wrapper

#!/bin/sh
export PATH=/cadappl/python3/3.10.5/python3/bin:${PATH}
export LD_LIBRARY_PATH=/cadappl/python3/3.10.5/python3/lib:/cadappl/tcl/8.6.11/tcl/lib:/cadappl/tk/8.6.11/tk/lib:/cadappl/sqlite/3.34.1/sqlite/lib:/cadappl/zlib/1.2.11/lib:/cadappl/openssl/1.1.1j/openssl/lib:/cadappl/valgrind/3.16.1/valgrind/lib:/cadappl/gdbm/1.19/gdbm/lib:/cadappl/readline/6.2.4.1/readline/lib:/cadappl/bzip2/1.0.6.a/bzip2/lib:${LD_LIBRARY_PATH}

`basename $0` "$@"

[konstin]

It's probably because we resolve the symlink so the basename changes

[csalerno-asml]

is there a workaround that I could apply in python3.wrapper? or this is something that should be fixed in uv?

[charliermarsh]

@konstin - Related to #1640 -- I'm unsure if we should be resolving symlinks for interpreters outside of virtualenvs.

[konstin]

We should stop resolving the symlinks unconditionally; Initially, it looked like a convenient solution for venv-from-venv use cases, but using sys._base_executable with a fallback to resolving should represent the user intent better.

[charliermarsh]

@konstin - I generally agree, although if we change that, it will "break" cases like this: pypa/virtualenv#2682. (That issue motivated virtualenv to start recursively resolving symlinks (on main but unreleased).)

[konstin]

I've asked at python/cpython#106045 (comment), this should bring some clarity

[Crissal1995]

Hi, is there any update regarding this issue?

[konstin]

We've rewritten interpreter discovery and this should not occur anymore, feel free to reopen if it's still a problem.