UV venv doesn't work on MacOS when Rye is installed

[justinhauer]

Summary:
Out of the box, the tool doesn't work.

I have Rye installed in my system. When downloading UV to test this out, as it seems like Rye will soon be dead and I'll have to migrate to this tool. I get the following error:

uv platform: MacOS 14.4 (Intel x86)
uv version: uv 0.1.6

command:
uv venv test
× Querying Python at /Users/justin/.rye/shims/rye failed with status exit
│ status: 2:
│ --- stdout:
--- stderr:
│ error: unexpected argument found
│ ---

It appears that with both tools installed, UV is nerfed.

[zanieb]

Thanks for the report! Rye won't be dead soon, we'll be helping maintain it.

Regarding the error, it seems weird that we're detecting rye as a Python executable. Can you provide output with the -v flag?

[methane]

This is why this error happens.

uv/crates/uv-interpreter/src/python_query.rs

Lines 174 to 175 in 5d53040

	let base_python = fs_err::canonicalize(python)?;
	let interpreter = Interpreter::query(&base_python, platform, cache)?;

$ which python3
/Users/inada-n/.rye/shims/python3

$ python3 get_interpreter_info.py
{"markers": ...}

$ ~/.rye/shims/rye get_interpreter_info.py
error: unrecognized subcommand

Anyway, rye doesn't provide commands like python3.12 so we can not rye venv -p3.12 too.
More effort is needed to support rye managed python interpreters.

[MichaReiser]

I haven't used rye myself but I wonder if this is the suggested workflow. I think the proposed way of using uv with rye is to use uv through rye. I think you can do that by setting rye config --set-bool behavior.use-uv=true. See https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/

[methane]

rye doesn't have rye venv command. We can not create venv without project for now.

[mitsuhiko]

@zanieb i ran into that issue myself. The problem here is that the python and python3 shim by rye is detected by name. When uv canonicalizes, it tries with the rye name instead. For uv usage within rye that's not an issue because i always bypass the paths where this shows up, but it is an issue if you point it directly to one of the rye shims.

I see three options:

1. pass a hidden env var as part of discovery that can force on the flag in uv
2. always let rye hardlink the shims on all platforms to prevent the symlink resolving
3. to not resolve symlinks in uv

[methane]

Virtualenv can extend Python discovery and there are extensions for pyenv and rye.

• https://virtualenv.pypa.io/en/latest/extend.html
• https://github.com/un-def/virtualenv-pyenv
• https://github.com/bluss/virtualenv-rye-discovery

Since it needs to be written in Python, difficut to support them from uv.

Another idea is creating directory like what scripts/bootstrap/install.py creates.
The directory containing python3 (default), python3.X, and python3.X.Y symlinks.
Shell script or Python script is enough for creating such directory for pyenv/rye.

uv already have UV_TEST_PYTHON_PATH for finding python from such directory.
By adding the directory to PATH temporary, tox and virtualenv can use it without extension.

[MichaReiser]

Possibly related to #1795

[methane]

I find uv venv -p3.8 spam doesn't canonicalize symlink.

uv/crates/uv-interpreter/src/python_query.rs

Lines 50 to 54 in 5d53040

	let formatted = PathBuf::from(format!("python{}.{}", versions[0], versions[1]));
	let Some(executable) = Interpreter::find_executable(&formatted)? else {
	return Ok(None);
	};
	let interpreter = Interpreter::query(&executable, platform, cache)?;

Why only find_default_python canonicalize python? Can we just stop canonicalize?