Opinion on Windows free-threaded installer design

[zooba]

(See python/cpython#112984 (comment) for full context)

I want to verify that the design for installing free-threaded binaries on Windows meets the SC's intentions in terms of how accessible/obvious/usable they should be at this stage.

The option in my current PR is the last checkbox on the third page of the installer, which users only see if they choose "Advanced" options.

If the option is selected, the binaries are downloaded by the installer from python.org. Pros: installer download doesn't get much larger, we can get independent download stats for freethreaded builds. Cons: option won't work without an internet connection, explicit download¹ gets bigger. (For context, the freethreaded binaries are approx 3MB, the symbols are 9MB and debug binaries are 14MB. To get these latter ones you'd select the two checkboxes above the freethreaded one.)

After install, there are python3.13t.exe and pythonw3.13t.exe installed alongside the usual python.exe and pythonw.exe. If the user has added to PATH, these will also be on PATH. The stdlib extension modules include a .cp313t-win<plat>.pyd ABI tag so that the correct build will be used. All pure-Python files are shared.

There's no way to install free-threaded Python without installing the regular build. There are separate Start menu shortcuts for the two python.exe binaries, but IDLE is only linked for the regular build.

We'll also publish a Nuget package under the name python<plat>-freethreaded, mainly for CI systems that are going to find it harder to run the installer to get the binaries.² These will only have freethreaded binaries, and will include a python.exe alias so that tools can select either kind of package and not have to switch their subsequent commands.

No embeddable distro or Windows Store package at this time.

---

Overall, this is the simplest and lowest risk option given our current set of releases. It minimises the number of downloads listed on our release page (none added, will add a note pointing to a docs section on the new checkbox) and makes it unlikely that "normal" users will get incompatible binaries by accident.

The only other simple option I seriously considered was changing the Nuget package for a regular ZIP file and putting it on python.org. However, without adding regular builds in the same way, people will definitely get confused by it (they already get confused by what's there). So that option adds at least 4 extra rows,³ which I don't believe is helpful to users.

---

I'm not doing this as a PEP because I'm trying to minimise work. Asking all contributors to design a single checkbox will inevitably result in people trying to redesign everything about our Windows release. I'm not prepared to deal with that personally :) If you'd really like a PEP, you'll have to find a volunteer to manage it.

Footnotes

1. There is a /layout command-line option on the installer to download all optional components, so you don't have to download them later. ↩

2. A Nuget package is essentially just a ZIP file with enough API to let tools do basic dependency resolution. cibuildwheel already uses our packages, for example. ↩

3. Three for the existing normal builds and one if we only do freethreaded for x64. More if we release binaries for all platforms, as in the current plan. ↩

[Yhg1s]

What you have seems fine, although the SC would like for it to be clearly experimental (like having (experimental) at the end of the option text). It may also make sense to wait for actual free-threaded binaries to be available, but you can co-ordinate that with Sam and the others doing the actual work.

[zooba]

Thanks. I'll add an experimental tag and merge the changes.

There'll be a build option at release time for whether to include it or not. If unselected, nothing appears different in the installer.