Exit after versions --update instead of falling through#305
Open
dwoz wants to merge 5 commits into
Open
Conversation
The argparse block in pyversions.main exits cleanly after `--update-deps` but `--update` had no `sys.exit(0)`, so it fell through into the `if args.version:` block. `--version` defaults to "3.14", so every `relenv versions --update` run ended by printing the latest 3.14.x — mistakable for "I just added 3.14.6" output when really it was just the implicit version lookup running. Mirror the --update-deps shape: exit after the update finishes.
Previous attempt invoked vs_installer.exe with an explicitly-quoted
installPath; it bailed with exit 87 (invalid parameter). Two changes:
- Use `Installer\setup.exe` (the VS bootstrapper) and fall back to
vs_installer.exe. setup.exe is what Microsoft documents as the
bootstrapper for modify operations.
- Pass --installPath as a bare PowerShell argument (let Start-Process
quote it), drop the manual backtick-quotes that confused the parser.
Also stop trusting the bootstrapper's exit code — VS Installer returns
non-zero in several benign cases. Verify by checking that MSBuild can
see the v140 platform toolset:
${env:ProgramFiles(x86)}\MSBuild\Microsoft.Cpp\v4.0\V140
If that path exists after the modify call, the toolset is registered
and Python's PCbuild can use it.
Previous attempt passed the bootstrapper arguments as a PowerShell array; Start-Process then concatenated them without re-quoting, so `C:\Program Files\Microsoft Visual Studio\18\Enterprise` was parsed as separate positional arguments and the installer rejected the call with exit 87. Build the command line as a single string with embedded double quotes around $VS_INST_LOC. Start-Process forwards that verbatim, the installer sees a properly-quoted --installPath, and the modify operation proceeds.
Verified against the real Visual Studio Installer (4.x) on a Windows 11 box: passing --wait makes the bootstrapper bail before parsing anything else with "Option 'wait' is unknown" and exit code 87 — the mystery exit-87 we kept hitting in CI. --quiet already runs the modify synchronously, and Start-Process -Wait in PowerShell still ensures we don't return until the bootstrapper process exits. Tested locally: the full install_vc_build.ps1 -CICD now reports "Ensuring v140 toolset is installed: Already present" on an existing VS install, and the standalone modify call returns exit 0.
After v140 install succeeded, Python 3.11.15 PCbuild started failing
on the windows-latest runner with:
\ucrt\wchar.h(443): error C2440: 'initializing': cannot convert
from 'int' to '__m128i'
Two related causes, both fixed here:
- The bootstrapper was warning "Cannot find package:
Microsoft.VisualStudio.Component.Windows81SDK in product graph" —
that component was removed in VS 2022+ / VS 18. No SDK was actually
installed alongside v140, so PCbuild fell back to the runner's only
SDK (Win11 SDK 10.0.26100.0), whose <wchar.h> uses SSE intrinsics
that v140 chokes on.
- Even with an older SDK installed, MSBuild auto-picks the newest one
unless told otherwise.
Install `Windows10SDK.19041` (Win10 SDK 2004, the latest known to pair
cleanly with v140 and Python's PCbuild) and pin the build step to it
via `WindowsTargetPlatformVersion`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The argparse block in pyversions.main exits cleanly after
--update-depsbut--updatehad nosys.exit(0), so it fell through into theif args.version:block.--versiondefaults to "3.14", so everyrelenv versions --updaterun ended by printing the latest 3.14.x — mistakable for "I just added 3.14.6" output when really it was just the implicit version lookup running.Mirror the --update-deps shape: exit after the update finishes.