Windows build favours NuGet over local install of branch version

[directhex]

Checklist

• I am confident this is a bug in CPython, not a bug in a third-party project
• I have searched the CPython issue tracker,
  and am confident this bug has not been reported before

CPython versions tested on:

3.11, 3.12, CPython main branch

Operating systems tested on:

Windows

Output from running 'python -VV' on the command line:

No response

A clear and concise description of the bug:

Windows builds of Python use a script called find_python.bat to locate a valid python.exe to use during the build.

It tries, in order:

1. whatever's in VIRTUAL_ENV
2. whatever's already in externals\pythonx86\tools\
3. query py.exe from $PATH, but only a permitted version, as per this line https://github.com/python/cpython/blob/main/PCbuild/find_python.bat#L45
4. downloading Python from the default configured NuGet repo (empty therefore nuget.exe defaults)

The problem is with case 3.

The permitted $PATH versions of Python to build 3.10 are 3.9 or 3.8 - if 3.10 is installed, it is ignored and 3.12RC1 from NuGet is used instead

The permitted $PATH versions of Python to build 3.11 are 3.10 or 3.9 - if 3.11 is installed, it is ignored and 3.12RC1 from NuGet is used instead

The permitted $PATH versions of Python to build 3.12 are 3.11, 3.10 or 3.9 - if 3.12 is installed, it is ignored and 3.12RC1 from NuGet is used instead

The permitted $PATH versions of Python to build main are 3.11, 3.10 or 3.9 - if main is installed, it is ignored and 3.12RC1 from NuGet is used instead

This behaviour is clearly wrong (especially since the version downloaded in the fallback case 4 is not version locked, so right now it's 3.12RC1 and doesn't account for compatibility breakages). Version X should always be in the permitted list to build version X.

3.9 did allow builds from a system install of 3.9, but this seems like an accident rather than design.

Linked PRs

• gh-108051: Update versions found by find_python.bat and clarify readme #116118

[zooba]

It shouldn't be installing 3.12.0-rc1 from Nuget - without the -Prerelease option it will choose the latest 3.11. If you've got global Nuget configuration on your machine then that may be being overridden, but I don't think there's anything we can change (apart from unconditionally using prereleases, which we don't want to do).

Given the complexity in finding an existing copy of Python that's going to work (especially as people change our bootstrap scripts to require ever-more-recent releases), I'd be more inclined to make it only use the Nuget install unless you specify HOST_PYTHON (and it's recent enough), and stop using other mechanisms to search for installs at all. It's just more reliable, and we already have a dependency on having an internet connection at this stage of building.

But since we're now building 3.13, there's no issue adding 3.12 to that list. Just needs a PR. Note that setting HOST_PYTHON=py -3.12 is meant to be valid, so that may be a good enough workaround if you don't know exactly where your copy of 3.12 is installed.

[encukou]

It looks like the options are:

• Adjust the release tools/notes to add a new version here when 3.xx.0-final is prepared
• Remove this logic altogether

@zooba, which would you prefer?

[zooba]

I'm not exactly sure which logic we'd be removing, but since it's probably going to upset other people if we remove any of it, leaving a comment/note to say we can/should update it after a release is fine. The PCbuild/readme.txt is probably sufficient.

The PR to allow a newer version should be easy enough, and having it noted will give people permission to send it. I don't feel any need to aggressively push it in, though.