[DRAFT&TEST] Apply PIP_CONSTRAINT when installing relenv[toolchain] in CI - #70107
Open
charzl wants to merge 3 commits into
Open
[DRAFT&TEST] Apply PIP_CONSTRAINT when installing relenv[toolchain] in CI#70107charzl wants to merge 3 commits into
charzl wants to merge 3 commits into
Conversation
_install_requirements() installs relenv[toolchain] via a bare
`pip install` before PIP_CONSTRAINT is set up (that happens later,
inside _upgrade_pip_setuptools_and_wheel() and the main requirements
install). Without the constraint, this call can pull in a newer pip
than the 25.2 pinned in requirements/constraints.txt, and relenv's
runtime patch of pip's InstallRequirement.install() breaks against
newer pip's changed signature:
TypeError: InstallRequirement.install() got an unexpected
keyword argument 'script_executable'
Reproduced on CI Deps across Linux (x86_64/arm64), macOS (x86_64/
arm64), and Windows (amd64/x86) -- all six failed with this same
traceback. Passing the same PIP_CONSTRAINT used everywhere else in
this function keeps this install pinned to the pip version relenv's
onedir actually ships with and is tested against.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
charzl
changed the title
2 tasks
The relenv[toolchain] install this function runs was completely unversioned -- always installing whatever's latest on PyPI at CI run-time, regardless of the relenv_version pinned everywhere else in the repo (cicd/shared-gh-workflows-context.yml, and the relenv-version inputs rendered from it into ci.yml/nightly.yml/ staging.yml/scheduled.yml). That drift is what let this exact class of bug in: an unpinned relenv release picked up a pip API change before relenv's own compatibility shim (see the parent commit) had adapted to it. RELENV_VERSION now reads the same relenv_version value out of cicd/shared-gh-workflows-context.yml -- the single source of truth tools/pkg/build.py already falls back to -- via a plain line-scan instead of a full YAML parse, since this module is imported by bare `nox` before any session venv (and therefore PyYAML) exists. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Summary
_install_requirements()innoxfile.pyinstallsrelenv[toolchain]via a barepip installcall, beforePIP_CONSTRAINTis set up (that happens later, inside_upgrade_pip_setuptools_and_wheel()and the main requirements install). Without the constraint, this call can pull in a newer pip than thepip == 25.2pinned inrequirements/constraints.txt, and relenv's runtime patch of pip'sInstallRequirement.install()breaks against newer pip's changed signature:This was reproduced on
CI Depsacross all six platform jobs (Linux x86_64/arm64, macOS x86_64/arm64, Windows amd64/x86) on #70099 -- all failed with the same traceback at thepip install 'relenv[toolchain]'step.Fix
Pass the same
PIP_CONSTRAINTenv var already used everywhere else in this function to this call too, keeping the install pinned to the pip version relenv's onedir actually ships with and is tested against.Test plan
requirements/constraints.txtalready pinspip == 25.2specifically because "pip 25.2 is the version that relenv's onedir ships with."🤖 Generated with Claude Code