fix: [make upgrade] always use pinned pip for bootstrapping - #708
Merged
Merged
Conversation
pip-tools==7.6.0 is incompatible with newer pip releases (pip's
RequirementCommand.make_requirement_preparer() now requires an
allow_editables kwarg that pip-tools 7.6.0 doesn't pass), which was
crashing every weekly Upgrade Python Requirements run with:
TypeError: RequirementCommand.make_requirement_preparer() missing
1 required keyword-only argument: 'allow_editables'
The root cause is that `make upgrade` only installed the pinned
pip-tools before compiling, so pip-compile bootstrapped against
whatever ambient (unconstrained) pip the CI runner had, rather than
this repo's own known-good pinned pip. Install requirements/pip.txt
alongside pip-tools before running pip-compile so the correct,
compatible pip/pip-tools pairing is always used, mirroring the fix
applied in edx/enterprise-subsidy for the same failure.
Re-ran `make upgrade` to regenerate requirements/*.txt with pip-tools
7.6.1 and pip 26.2 (now properly constrained via common_constraints.txt).
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
The requirements bump in this PR pulls in edx-lint 6.2.0, whose PII
annotation pylint plugin now requires a [PII] pii-terms setting in
pylintrc, raising:
ValueError: The 'pii_terms' setting must be configured.
and crashing the quality check entirely. Regenerated pylintrc via
`edx_lint write pylintrc` to pick up the new [PII] section (using
edx-lint's own default pii-terms list), per the file's own
instructions for staying in sync with edx-lint.
pwnage101
approved these changes
Sep 17, 2026
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
2 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.
What
The weekly "Upgrade Python Requirements" workflow has been failing for the last several runs with:
This is a
pip/pip-toolsAPI incompatibility:pip-tools==7.6.0's resolver calls pip's internalRequirementCommand.make_requirement_preparer()without a keyword arg (allow_editables) that newerpipreleases now require.Root cause
make upgrade'spiptools-requirementstarget only installed the pinnedpip-toolsbefore compiling:It never installed this repo's own pinned
pipfirst, sopip-compilebootstrapped against whatever (unconstrained, and in this case too-new)pipthe CI runner happened to have, rather than a known-good pinned version — causing the crash on the very firstpip-compileinvocation.Fix
requirements/pip.txtalongsidepip-tools.txt(constrained viarequirements/constraints.txt) before compiling, so a known-good pip/pip-tools pairing is always used to bootstrap:pip==26.2.1/pip-tools==7.6.0pins inrequirements/pip.txt/requirements/pip_tools.txtto a compatible pairing (pip==26.2,pip-tools==7.6.1), which was needed once to break the cycle since the committed pin was already on the broken version.make upgradeto regenerate allrequirements/*.txtfiles.pipis now properly constrained going forward viacommon_constraints.txt(pip<26.2.1, upstreamed in edx-lint).This mirrors the same fix applied for the identical failure in
edx/enterprise-subsidy.Test plan
make upgradecompletes locally without theallow_editablesTypeErrorrequirements/pip.txtshowspip==26.2constrained viacommon_constraints.txt