Add support for free threaded Python

[t-kalinowski]

Pointing reticulate at a freethreaded Python build currently raises an error. We need to investigate, diagnose the issue, and fix it.

We should also make it easy to select a freethreaded Python in py_require(), e.g., accept py_require(python = "3.14t").

Additionally, I noticed that uv has changed its behavior since I last checked. Versions without a patch level, like 3.13, used to resolve to 3.13.0. However, with the latest version of uv, 3.13 now resolves to 3.13.8. We can probably simplify resolve_python_version() now.

[sounkou-bioinfo]

Is there some container setup to test this out ?

[t-kalinowski]

There is not currently, as we haven't had need for it since the Python C API is quite good about maintaining C API compatibility. https://docs.python.org/3/c-api/stable.html

From a glance, it looks like the Python C functions we call in reticulate are still valid in the free-threaded builds of Python https://docs.python.org/3/howto/free-threading-extensions.html#thread-state-and-gil-apis.

[sounkou-bioinfo]

There is not currently, as we haven't had need for it since the Python C API is quite good about maintaining C API compatibility. https://docs.python.org/3/c-api/stable.html

From a glance, it looks like the Python C functions we call in reticulate are still valid in the free-threaded builds of Python https://docs.python.org/3/howto/free-threading-extensions.html#thread-state-and-gil-apis.

It looks like the uv error is linked to this issue astral-sh/uv#6812, using python3.14 works fine using use_venv, python3.14t errors

to reproduce

UV_VENV_CLEAR=1 uv venv --python  python@3.14
uv run Rscript -e 'library(reticulate);use_virtualenv(".venv/");os <- import("os")'
UV_VENV_CLEAR=1 uv venv --python  python@3.14t
uv run Rscript -e 'library(reticulate);use_virtualenv(".venv/");os <- import("os")'

output

UV_VENV_CLEAR=1 uv venv --python  python@3.14
uv run Rscript -e 'library(reticulate);use_virtualenv(".venv/");os <- import("os")'
UV_VENV_CLEAR=1 uv venv --python  python@3.14t
uv run Rscript -e 'library(reticulate);use_virtualenv(".venv/");os <- import("os")'
Using CPython 3.14.0
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
Using CPython 3.14.0
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
Error: '/root/reticulate/.venv/bin/python' was not built with a shared library.
reticulate can only bind to copies of Python built with '--enable-shared'.
Execution halted

note though that using this script https://gist.githubusercontent.com/tkf/d980eee120611604c0b9b5fef5b8dae6/raw/36bd53aa36bbe7fa06412b07cf72437361549dd3/find_libpython.py

UV_VENV_CLEAR=1 uv venv --python  python@3.14t
uv run tools/find_libpython.py |paste
#/root/.local/share/uv/python/cpython-3.14.0+freethreaded-linux-x86_64-gnu/lib/libpython3.14t.so.1.0
UV_VENV_CLEAR=1 uv venv --python  python@3.14
uv run tools/find_libpython.py |paste
#/root/.local/share/uv/python/cpython-3.14.0-linux-x86_64-gnu/lib/libpython3.14.so.1.0

the uv people are not naming in an uniform manner the libpython shared library or this is an error of my usage of reticulate

[sounkou-bioinfo]

in this pull request #1857 i added a change to find the threaded python shared library in uv environments . At least on ubuntu, this leads to a segfault indicating ABI changes that may necessitate changes to to src/libpython.cpp and src/python.cpp because likely in the free threaded builds, the GIL variables are removed. I don t know if this segfault is reproducible for other threaded python build setups

[t-kalinowski]

Thank you for doing the initial investegation! This is very helpful!