mise uses free-threaded Python 3.13 (`3.13.0t`) when specifying `3.13`

[halms]

Describe the bug Python 3.13 is released now and it allows an optional experimental support for free-threading (no GIL). These builds usually have a t suffix and python-build supports those. Now the version selection logic of mise prefers 3.13.0t over 3.13.0 when specifying mise use python@3.13. (It works fine with mise use python@3.13.0)

I assume this to be an annoying case because for some tools an appended letter means some kind of minor/patch version (e.g. OpenSSL 1).

To Reproduce

$ mise use -g python@3.13
[... python-build output]
mise python@3.13.0t ✓ installed
mise ~/.config/mise/config.toml tools: python@3.13.0t

$ python3.13 -VV
Python 3.13.0 experimental free-threading build (main, Oct  8 2024, 12:50:41) [GCC 13.2.0]

mise doctor output

version: 2024.10.1 linux-x64 (2024-10-07)
activated: yes
shims_on_path: yes

build_info:
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS
  Built: Mon, 7 Oct 2024 19:01:35 +0000
  Rust Version: rustc 1.81.0 (eeb90cda1 2024-09-04) (Homebrew)
  Profile: release

shell:
  /bin/bash
  GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
  Copyright (C) 2022 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

  This is free software; you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

dirs:
  data: ~/.local/share/mise
  config: ~/.config/mise
  cache: ~/.cache/mise
  state: ~/.local/state/mise
  shims: ~/.local/share/mise/shims

config_files:
  ~/.config/mise/config.toml

backends:
  cargo
  core
  go
  npm
  pipx
  spm
  ubi
  vfox

plugins:
  terraform  https://github.com/asdf-community/asdf-hashicorp.git#f1602b6
  usage      https://github.com/jdx/mise-usage.git#fe3888a

toolset:
  go@1.23.2
  node@20.18.0
  bun@1.1.29
  usage@0.8.4
  python@3.13.0

env_vars:
  MISE_SHELL=bash

settings:
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf = true
  asdf_compat = false
  cache_prune_age = "30d"
  cargo_binstall = true
  ci = false
  color = true
  debug = false
  disable_default_shorthands = false
  disable_hints = []
  disable_tools = []
  experimental = true
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  http_timeout = 30
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  libgit2 = true
  log_level = "info"
  not_found_auto_install = true
  paranoid = false
  pin = false
  pipx_uvx = true
  plugin_autoupdate_last_check_duration = "7d"
  python_default_packages_file = "~/.default-python-packages"
  python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
  python_venv_auto_create = false
  quiet = false
  raw = false
  trace = false
  trusted_config_paths = []
  use_versions_host = true
  verbose = false
  vfox = false
  yes = false

  [node]

  [ruby]
  default_packages_file = "~/.default-gems"
  ruby_build_repo = "https://github.com/rbenv/ruby-build.git"
  ruby_install = false
  ruby_install_repo = "https://github.com/postmodern/ruby-install.git"

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false
No warnings found
No problems found

[finalchild]

related: java latest resolves to the loom variant

[roele]

@finalchild In case of Java it is because there is no other (OpenJDK) 24.x version and Loom versions were not properly treated as early access by https://github.com/joschi/java-metadata for unknown reason. Also Java vendors adhere to proper semantic versioning which makes it easier to compare, sort etc. while 3.13.0t certainly is not.

[jdx]

to be clear, this is limited to python-build, correct? I think what we should probably do is have both a setting and tool option for configuring this but make the default non-free threaded

[jdx]

or maybe as a simpler option, it appears that python-build configures this with PYTHON_BUILD_FREE_THREADING=1

so what we could instead do is just never use the "t" variants but people could install it by setting that env var and we could just document that.

[halms]

This specific behavior (t suffix) only affects python-build. The precompiled versions use a freethreaded build tag to differentiate.

Setting the env var works for python-build, but not for precompiled.

Maybe I'm off here, but ideally I'd see the freethreaded version as a separate variant like cpython-freethreaded-3.13 or just freethreaded-3.13 or something like that. While it might be interesting to support explicitly choosing these version/builds, I think this is out of scope for this bug.

For now the focus is probably really just ignoring the t versions. Probably removing these from the candidate list is easier than having the solver not pick the t version by default?

[jdx]

For now the focus is probably really just ignoring the t versions.

that's what my "simpler" solution is