I didn't think to check 3.12-lowest locally before putting up this PR. 🤔 I bet I can fix that, but I'll need to work out how.

Both of the Windows builds are failing on the same test.

________________ test_invalid_pip_version_in_python_executable ________________
[gw2] win32 -- Python 3.12.10 C:\a\pip-tools\pip-tools\.tox\pipsupported-coverage\Scripts\python.EXE

get_pip_version_for_python_executable = <MagicMock name='get_pip_version_for_python_executable' id='2746640405168'>
runner = <click.testing.CliRunner object at 0x0000027F808F91C0>
tmp_path = WindowsPath('C:/Users/runneradmin/AppData/Local/Temp/pytest-of-unknown/pytest-0/popen-gw2/test_invalid_pip_version_in_py0')

    @mock.patch("piptools.scripts.sync.get_pip_version_for_python_executable")
    def test_invalid_pip_version_in_python_executable(
        get_pip_version_for_python_executable, runner, tmp_path
    ):
        with open(sync.DEFAULT_REQUIREMENTS_FILE, "w") as req_in:
            req_in.write("small-fake-a==1.10.0")
    
        custom_executable = tmp_path / "custom_executable"
        custom_executable.write_text("")
    
        custom_executable.chmod(0o700)
    
        get_pip_version_for_python_executable.return_value = Version("19.1")
    
        out = runner.invoke(cli, ["--python-executable", str(custom_executable)])
        assert out.exit_code == 2, out
        message = (
            "Target python executable '{}' has pip version 19.1 installed. "
            "Version"  # ">=20.3 is expected.\n" part is omitted
        )
>       assert out.stderr.startswith(message.format(custom_executable))
E       assert False
E        +  where False = <built-in method startswith of str object at 0x0000027F807B7C90>("Target python executable 'C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-0\\popen-gw2\\test_invalid_pip_version_in_py0\\custom_executable' has pip version 19.1 installed. Version")
E        +    where <built-in method startswith of str object at 0x0000027F807B7C90> = "Could not resolve 'C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-0\\popen-gw2\\test_invalid_pip_version_in_py0\\custom_executable' as valid executable path or alias.\n".startswith
E        +      where "Could not resolve 'C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-0\\popen-gw2\\test_invalid_pip_version_in_py0\\custom_executable' as valid executable path or alias.\n" = <Result SystemExit(2)>.stderr
E        +    and   "Target python executable 'C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-0\\popen-gw2\\test_invalid_pip_version_in_py0\\custom_executable' has pip version 19.1 installed. Version" = <built-in method format of str object at 0x0000027F80541DF0>(WindowsPath('C:/Users/runneradmin/AppData/Local/Temp/pytest-of-unknown/pytest-0/popen-gw2/test_invalid_pip_version_in_py0/custom_executable'))
E        +      where <built-in method format of str object at 0x0000027F80541DF0> = "Target python executable '{}' has pip version 19.1 installed. Version".format

Looks like it's a test which creates a dummy/stub file to use as a fake python executable, and then passes that to --python-executable for the test.
The failure, dug out of that log, is

Could not resolve 'C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-0\\popen-gw2\\test_invalid_pip_version_in_py0\\custom_executable' as valid executable path or alias.\n

That comes from scripts/sync.py, where there's this check:

resolved_python_executable = shutil.which(python_executable)
if resolved_python_executable is None:
    msg = "Could not resolve '{}' as valid executable path or alias."
    log.error(msg.format(python_executable))
    sys.exit(2)

shutil.which has notes about Python 3.12 changes on Windows, specifically. Current doc:

Changed in version 3.12: On Windows, the current directory is no longer prepended to the search path if mode includes os.X_OK and WinAPI NeedCurrentDirectoryForExePathW(cmd) is false, else the current directory is prepended even if it is already in the search path; PATHEXT is used now even when cmd includes a directory component or ends with an extension that is in PATHEXT; and filenames that have no extension can now be found.

That phrasing sounds like nothing should be impactful here, but my speculation is that the updated PATHEXT behavior is expecting to find .exe as a suffix. I'll look at the changes to shutil.which in 3.12 to see if I can understand it better by going source diving.

@sirosen sounds like that's solvable by appending .exe? At least, this should demonstrate if the assumption is correct.

Also add the 3.12 classifier:

https://github.com/jazzband/pip-tools/blob/e4ed0c1e028d1ca73673a51722ba153f0c02b0c6/pyproject.toml#L22-LL26

@sirosen sounds like that's solvable by appending .exe? At least, this should demonstrate if the assumption is correct.

That was my expectation, and I tried to verify it by pushing a test commit to my fork (separate branch) to run CI with this.
I've pushed the change here as well.

I don't "fully get it" because it seems to me like an absolute path ought to succeed if there's an executable file there? But I'm not very knowledgeable about Windows, so maybe this PATHEXT behavior in shutil.which() is really more correct.

It seems to work, but I lost a bit of time not trusting the fix because the CI output on success was not what I expected to see. We're only getting the successful run of a tox environment reported, not the pytest output. I'm not clear on why that is.

I've also modified the primary commit for 3.12 support with co-author info + added a change co-authored by Hugo for the classifier.

Assuming this passes in CI, I feel happy with the result!

We're only getting the successful run of a tox environment reported, not the pytest output. I'm not clear on why that is.

@sirosen wow! This is bizarre! I didn't realize. I don't see an obvious explanation for this behavior.

This may be tox-dev/tox#3193, but I thought it was addressed already. It's not been happening in most of my other projects, but I'm seeing https://github.com/cherrypy/cheroot/actions/runs/15088798220/job/42414767484#step:16:1 using a command with more CLI args, perhaps that's why.

Could you validate this guess?

We're only getting the successful run of a tox environment reported, not the pytest output. I'm not clear on why that is.

@sirosen wow! This is bizarre! I didn't realize. I don't see an obvious explanation for this behavior.

This may be tox-dev/tox#3193, but I thought it was addressed already. It's not been happening in most of my other projects, but I'm seeing cherrypy/cheroot/actions/runs/15088798220/job/42414767484#step:16:1 using a command with more CLI args, perhaps that's why.

Could you validate this guess?

Yep. That was it. We can merge #2190 right after merging this PR.

Excellent job tracking that down! I was thinking it looked like parallel output but I didn't see where we're setting that. I'll wait for CI and then we should be able to merge this one.