Fix pip 26.2 compatibility in InstallRequirement.install/install_wheel wrappers - #314
Open
twangboy wants to merge 2 commits into
Open
Fix pip 26.2 compatibility in InstallRequirement.install/install_wheel wrappers#314twangboy wants to merge 2 commits into
twangboy wants to merge 2 commits into
Conversation
charzl
approved these changes
Jul 31, 2026
dwoz
approved these changes
Jul 31, 2026
…l wrappers pip 26.2 added a new `script_executable` parameter to both InstallRequirement.install() and install_wheel(), as part of its new venv-based build-isolation feature. relenv's wrap_req_install patches InstallRequirement.install by counting positional arguments and replaying one of three hardcoded call shapes (7/8/9 args); none of them accept unrecognized keywords, so pip calling with script_executable= fails at the wrapper's own argument-binding with TypeError: InstallRequirement.install() got an unexpected keyword argument 'script_executable'. Worse, pip 26.2's 8-arg shape collides with pip 25.2's existing 8-arg shape (global_options vs. script_executable), so this isn't fixable by adding another argcount branch. install_wheel_wrapper has the identical hardcoded-positional-args problem one call deeper, since InstallRequirement.install() forwards script_executable straight into install_wheel(). Replace the argcount-branching in wrap_req_install with a single wrapper built from inspect.signature() of whatever install() actually is at runtime, so it tolerates any pip signature as long as `home` stays a named parameter (true across every version checked: 25.2, 26.1, 26.2) and forwards everything else untouched. Fail loudly with RuntimeError at bootstrap time if `home` ever disappears, instead of silently breaking TARGET installs. install_wheel_wrapper now forwards its trailing arguments via *args/**kwargs instead of a fixed 8-arg list, for the same reason. Verified against a real relenv-built Python upgraded to pip 26.2: `pip install 'relenv[toolchain]'` (the exact command failing in CI) now succeeds, and the existing pip-25.2/25.3 compatibility tests still pass alongside a new 26.2 case.
CPython's PCbuild\find_python.bat searches for a pre-installed bootstrap interpreter via specific "py -X.Y" versions before falling back to downloading one via NuGet. The 3.10 branch's copy of this script only tries "py -3.9" and "py -3.8" (3.11's tries 3.10/3.9 instead) — both 3.9 and 3.8 are now EOL and have aged out of GitHub's hosted Windows runner images, so that search always comes up empty when building 3.10. The NuGet fallback it then hits is separately broken in our CI right now, failing with "The system cannot execute the specified program" / "Cannot locate python.exe on PATH or as PYTHON variable". This reproduces 100% of the time building 3.10 on Windows and explains why retrying the CI job never helped: 3.11+ never even touch this path because they successfully match an already-present "py -3.10". find_python.bat checks a HOST_PYTHON environment variable before either the version-specific search or the NuGet fallback. Set it in populate_env() to sys.executable — the interpreter already running the build — so PCbuild always finds a usable bootstrap Python directly and never depends on legacy py-launcher registrations or a NuGet download succeeding.
twangboy
force-pushed
the
fix/pip-26.2-script-executable
branch
from
July 31, 2026 20:24
dad84bf to
daa0ac1
Compare
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
3 participants
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.
pip 26.2 added a new
script_executableparameter to both InstallRequirement.install() and install_wheel(), as part of its new venv-based build-isolation feature. relenv's wrap_req_install patches InstallRequirement.install by counting positional arguments and replaying one of three hardcoded call shapes (7/8/9 args); none of them accept unrecognized keywords, so pip calling with script_executable= fails at the wrapper's own argument-binding with TypeError: InstallRequirement.install() got an unexpected keyword argument 'script_executable'.Worse, pip 26.2's 8-arg shape collides with pip 25.2's existing 8-arg shape (global_options vs. script_executable), so this isn't fixable by adding another argcount branch. install_wheel_wrapper has the identical hardcoded-positional-args problem one call deeper, since InstallRequirement.install() forwards script_executable straight into install_wheel().
Replace the argcount-branching in wrap_req_install with a single wrapper built from inspect.signature() of whatever install() actually is at runtime, so it tolerates any pip signature as long as
homestays a named parameter (true across every version checked: 25.2, 26.1, 26.2) and forwards everything else untouched. Fail loudly with RuntimeError at bootstrap time ifhomeever disappears, instead of silently breaking TARGET installs. install_wheel_wrapper now forwards its trailing arguments via *args/**kwargs instead of a fixed 8-arg list, for the same reason.Verified against a real relenv-built Python upgraded to pip 26.2:
pip install 'relenv[toolchain]'(the exact command failing in CI) now succeeds, and the existing pip-25.2/25.3 compatibility tests still pass alongside a new 26.2 case.