Allow creating venv with free-threaded python builds

[bschoenmaeckers]

Summary

closes #4828

First iteration for an implementation. I need to add more tests but wanted your opinion on the implementation first.

Test Plan

Currently tested using the following command but will add tests shortly:

D:\repo\uv> cargo run venv -p 3.13t && .venv\Scripts\python.exe
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.52s
     Running `target\debug\uv.exe venv -p 3.13t`
Using Python 3.13.0rc1 interpreter at: C:\Users\bschoen\AppData\Local\Programs\Python\Python313\python3.13t.exe
Creating virtualenv at: .venv
Activate with: .venv\Scripts\activate
Python 3.13.0rc1 experimental free-threading build (tags/v3.13.0rc1:e4a3e78, Jul 31 2024, 21:06:58) [MSC v.1940 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 

[bschoenmaeckers]

Working on the unix implementation now.

[bschoenmaeckers]

Working on the unix implementation now.

Tested it on linux using the quay.io/pypa/manylinux2014_x86_64 docker image and I seems to work correctly already. Going to write some tests next.

[bschoenmaeckers]

I find it quiet hard to add a test without a free-threaded build available in the CI. So maybe we should add a full integration test later when the downloadable build is available.

[bschoenmaeckers]

Should version requests like >=3.13t, >=3.13t,<3.14t or >=3.12,<3.14t be valid?

[zanieb]

Should version requests like >=3.13t, >=3.13t,<3.14t or >=3.12,<3.14t be valid?

Maybeee. It seems safe to add support for that later if people need it.

I find it quiet hard to add a test without a free-threaded build available in the CI. So maybe we should add a full integration test later when the downloadable build is available.

You can probably add test coverage in crates/uv-python/src/lib.rs, we support creating mock interpreters there.

[zanieb]

Oh also regarding an integration test, is there a Docker image with a free-threaded build? or a system that has it packaged? You can create a new integration-test CI job that does whatever so we get some real-world coverage.

[bschoenmaeckers]

I've added a smoke test in the ci using a pre-compiled python 3.13 package installed using apt-get on a bare ubuntu instance. Furthermore I added a mocked interpreter test.

[zanieb]

Doing some internal debate about this right now — this is sort of the "easiest" way to add support but it might be better to added a freethreaded: bool to each relevant variant instead? Like FreeThreaded(Any) shouldn't be allowed nor FreeThreaded(FreeThreaded(...)) right? Want to share some more about why you went with this pattern?

[bschoenmaeckers]

It was at the time of implementing the easiest option to wrap every variant with a FreeThreaded version because it didn't felt right to clutter every variant with yet another flag. You are right that that FreeThreaded(Any) does not make sense but the FreeThreaded(FreeThreaded(...)) should not be possible for the parser to generate, even though it would not be a very big problem because it would behave like a regular FreeThreaded(...) variant. But I understand the debate and would happily switch to a extra flag on every variant if you want me to.

[zanieb]

The parser can't generate it but this is a "public" enum so someone could construct that variant — which is a bit awkward. I think I have a preference for adding a boolean to the variants, it looks like it would make some of the downstream logic simpler. It is a bit sad that we'll need to add it everywhere we construct a VersionRequest manually but I'm not sure what else to do there. As a small note, it may need to be Option<bool> for cases in which the free-threaded build is fine, e.g., and can be used if it's first on the PATH.

[bschoenmaeckers]

Fine by me. How would you parse a 3.13 request? Does the user allow a free-threaded build or not?

[zanieb]

I'm not sure.

cc @henryiii / @carljm who may have helpful opinions on that.

[henryiii]

I think you want to make sure this can change for a future Python version, but yes, I think currently you want free-threaded to be opt-in. In the future, if it works well, it might be opt-out instead, maybe as soon as 3.15 (which may be called 3.27).

[zanieb]

What if you have a python executable at the front of your path and it's free-threaded?

[henryiii]

If it's called python or python3.13, then yes, but usually it's only called python3.13t?

[henryiii]

Same as pypy. If there's a python that's actually pointing at pypy, then that should be picked up, otherwise pypy should only be opt-in?

[zanieb]

Unfortunately people do weird things and we have to think about these edge-cases

[zanieb]

I think this is failing because it's not searching for the executable name properly. I'm going to tweak the possible_names and default_names code — it' really unwieldy (not from this pull request).

[bschoenmaeckers]

I think this is failing because it's not searching for the executable name properly. I'm going to tweak the possible_names and default_names code — it' really unwieldy (not from this pull request).

I was thinking so as well, I did not had time to debug this properly. The only thing I knew was that it is working properly on windows.

[bschoenmaeckers]

@zanieb, I fixed the tests. So it is ready for review again.

[zanieb]

Thanks! I resolved the conflicts with #7649

[basnijholt]

Awesome! Does this mean that there will be a 3.13t version available at the next release of uv?

[zanieb]

Unfortunately not, that's much harder and can be tracked at astral-sh/python-build-standalone#326

With this, we'll just let you ask uv to use a free-threaded build you already have installed.

[henryiii]

FYI, this means you can say "3.13t" and get it; you can already use uv with python3.13t as long as you give it via path. (At least I hope so, for example cibuildwheel does that)