wr does not respect uv python version selection

[npuichigo]

I got this error and try to use uv to pin another python version like

uv python install 3.13
uv python pin 3.13

But the error still try to use python 3.11

Failed to run:
        cd "exercises/01_intro/01_setup" && "cargo" "test"
Output:
            Finished `test` profile [unoptimized + debuginfo] target(s) in 0.00s
             Running unittests src/lib.rs (/home/ichigo/LocalCodes/github/rust-python-interoperability/target/debug/deps/setup-baf5e8db95fd11dd)
        /home/ichigo/LocalCodes/github/rust-python-interoperability/target/debug/deps/setup-baf5e8db95fd11dd: error while loading shared libraries: libpython3.11.so.1.0: cannot open shared object file: No such file or directory
        error: test failed, to rerun pass `--lib`

        Caused by:
          process didn't exit successfully: `/home/ichigo/LocalCodes/github/rust-python-interoperability/target/debug/deps/setup-baf5e8db95fd11dd` (exit status: 127)
        note: test exited abnormally; to see the full output pass --nocapture to the harness.

[npuichigo]

Another thing is if I change the requires-python version in pyproject.yaml to 3.13, there's no error about version mismatch and still show this 3.11 error.

[LukeMathWalker]

Another thing is if I change the requires-python version in pyproject.yaml to 3.13, there's no error about version mismatch and still show this 3.11 error.

Do you mean changing

[project]
name = "setup"
requires-python = ">=3.11"
version = "0.1.0"

to

[project]
name = "setup"
requires-python = ">=3.13"
version = "0.1.0"

?

[LukeMathWalker]

In terms of what's happening under the hood, you can see it in https://github.com/mainmatter/rust-python-interoperability/blob/main/.wr.toml

[npuichigo]

I read the issue you mentioned in uv and I think not a mac-only issue. I checked my successful build then and find that although I use 3.13 to build and .venv is created by uv in each subfolder automatically like

ichigo@ichigo:~/LocalCodes/github/rust-python-interoperability$ ls exercises/01_intro/01_setup/.venv/lib/
python3.13

The build is linked to a wrong so

ichigo@ichigo:~/LocalCodes/github/rust-python-interoperability$ ldd target/debug/deps/setup-baf5e8db95fd11dd
        linux-vdso.so.1 (0x00007ffd743f5000)
        libpython3.10.so.1.0 => /lib/x86_64-linux-gnu/libpython3.10.so.1.0 (0x00007f1066578000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1066558000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1066471000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1066248000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1066c3e000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1066217000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f10661f9000)

[LukeMathWalker]

There are two separate issues:

1. pyo3 is picking up system Python rather than uv Python. That's because the virtual environment is not activated when the cargo command is issued by wr. I have a fix for this part.
2. Fixing the above led me to the issue you saw on the uv repository. But that only affects macOS.

I'll open a PR once both are ready to go.

[LukeMathWalker]

2b34916 should have fixed the first point. Can you confirm? @npuichigo