Seems like the python path printing is borked now...

I think using UV_TEST_PYTHON_PATH isn't okay in the context of the system tests.

I think the interpreter that invokes the system test script is the one that should be used, right?

The test script interpreter is the one whose parent directory I am putting in UV_TEST_PYTHON_PATH. Although I agree it's kind of jank in retrospect. It could hide a bug in our path parsing.

As an alternative we could prepend to $env:PATH ¹ before running the script.

I think the real weird thing here is that there's no actual guarantee that py -3.9 would pick the chocolatey version if some other 3.9 was installed, but I couldn't find any good way to verify this invariant.

But at least I feel that setting $env:PATH prior to running the verification script would at least ensure that the script and uv both use the same python version.

Lastly, I could try to investigate why chocolatey's path changes aren't being picked up although I have a feeling that the answer is going to be either: "the registry changes can't be propagated to the runner without restarting the runner" or "github runners explicitly sanitize that somehow so the environment change doesn't persist".

I think the real weird thing here is that there's no actual guarantee that py -3.9 would pick the chocolatey version if some other 3.9 was installed, but I couldn't find any good way to verify this invariant.

Can't we just use the path that chocolatey is at instead of py -3.9? Maybe I'm missing something?

But yeah I think a point of these tests is uv's discovery of system Python versions, so overriding that with our custom test path seems janky. That variable shouldn't really be used in more places, it's quite the blemish already imo (I added it, alas)

Can't we just use the path that chocolatey is at instead of py -3.9? Maybe I'm missing something?

Yeah, sorry, I just realised there was a key bit of context I forgot:

It seems you can tell chocolatey where you'd like to put the installation, but it won't listen if that version is already installed (it will overwrite at the existing location). There also doesn't seem to be any good way of asking chocolatey where it did install it either.

This means using C:\Python39\ (the default path) could break if we revert the runner image or a future image starts shipping python 3.9 again.

But, having thought about it, prepending C:\Python39\ and then using C:\Python39\python.exe .\script is probably the safest option: it will fail if anything weird happens to the image which could cause us to e.g. start testing a non-chocolatey python version.

What might also work: We could try to set $env:PATH from the registry and invoke python instead of py -3.9. But we'd have to verify the version matches what we expect.

@zanieb I went with the approach of refreshing the path from the registry. Although this means that GITHUB_PATH won't work properly...

Dang it... It merges automatically even if system tests fail?

GitHub auto-merge can unfortunately only be configured on the required checks.