[FR]: Support free-threaded Python (3.13t/3.14t) wheel resolution with uv

[mkanat]

What is the current behavior?

When using rules_python's free-threaded Python toolchain (--@rules_python//python/config_settings:py_freethreaded=yes), aspect_rules_py's uv extension installs regular cp314 wheels instead of cp314t wheels.

You can reproduce it by depending on any package with a C extension (e.g., regex) and then trying to build with that flag while using the uv support.

The uv wheel installer resolves and installs wheels for the regular ABI (cp314). For example, regex gets installed with:

_regex.cpython-314-x86_64-linux-gnu.so

But the free-threaded interpreter (python3.14t) expects:

_regex.cpython-314t-x86_64-linux-gnu.so

Pure-Python packages are unaffected since they have no ABI-specific files.

Describe the feature

Just recognize that --@rules_python//python/config_settings:py_freethreaded=yes got set and select the right wheel.

[mkanat]

Oh, I see there's already a TODO about this in uv/private/constraints/abi/macro.bzl. :)

[arrdem]

Hey @mkanat -- It looks to me that this is supported in #778, which includes https://github.com/aspect-build/rules_py/blob/arrdem%2Ffix-718-multiversion-and-extras/uv/private/constraints/abi/macro.bzl#L105-L142 supporting freethreaded ABIs.

aspect_rules_py is currently somewhat but not completely compatible with how rules_python's toolchains and configurations are managed. In the future we will likely provide our own Python interpreter toolchains for simplicity. For the time being you should be able to define a custom platform() specifying constraints=[":freethreading_enabled"] and flags=["--@rules_python//python/config_settings:py_freethreaded=yes"] which should cause the respective pieces of machinery to behave as desired.

In the future when we provide interpreter toolchains, this won't be required.

[mkanat]

Okay, yeah, setting the platform worked. There is one interesting thing, though---I also had to register_execution_platforms in addition to setting --platformsor my py_tests wouldn't resolve:

defcl/python/validator/BUILD.bazel:74:12: While resolving toolchains for target //defcl/python/validator:format_test_Python_with_ruff (1c624c6): No matching toolchains found for types:
  @@bazel_tools//tools/test:default_test_toolchain_type: By default, tests are executed on the first execution platform that matches all constraints specified by the target platform. Either register the target platform (or a platform with at least the same constraints) as an execution platform, or override the default behavior by registering a custom toolchain for @bazel_tools//tools/test:default_test_toolchain_type.
To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/test:default_test_toolchain_type'
For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro.

I'm not quite sure how to reason through whether that's logically expected or not. I suppose it's always necessary since "python" is both the build tool and the execution tool?

[mkanat]

Also, I know that I pasted a format_test error, but it's not just format_test, it's also my py_test targets:

defcl/python/validator/BUILD.bazel:50:8: While resolving toolchains for target //defcl/python/validator:syntax_test (1c624c6): No matching toolchains found for types:
  @@bazel_tools//tools/test:default_test_toolchain_type

[arrdem]

From the linked issue

#805: select_chain picks abi3 wheels that segfault under the cp314t ABI (different struct layouts make standard-ABI extensions crash on load).

Ok that's a legitimate bug in the select chain ordering, can take a crack at that.