Skip to content

[Draft]Upgrade relenv from 0.22.14 to 0.22.22 - #70108

Open
charzl wants to merge 3 commits into
masterfrom
upgrade/relenv-0.22.22
Open

[Draft]Upgrade relenv from 0.22.14 to 0.22.22#70108
charzl wants to merge 3 commits into
masterfrom
upgrade/relenv-0.22.22

Conversation

@charzl

@charzl charzl commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

Summary

relenv 0.22.14 (currently pinned as relenv_version in cicd/shared-gh-workflows-context.yml and as an explicit relenv-version override in ci.yml/nightly.yml/staging.yml/scheduled.yml) monkeypatches pip's InstallRequirement.install() with a hardcoded wrapper signature (branching on argument count: 7/8/9/other).

When pip itself adds a new parameter to install()'s real signature -- most recently script_executable in pip 26.2 -- and pip's own internal caller (install_given_reqs()) starts passing it, that call lands on relenv's wrapper instead (since relenv replaced the method), whose hardcoded signature doesn't know about the new parameter:

TypeError: InstallRequirement.install() got an unexpected keyword argument 'script_executable'

This is what broke CI Deps on #70099 across all six platforms (see #70107 for the immediate mitigation -- pinning pip to the version relenv 0.22.14 was tested against for one specific unconstrained call site).

Root cause fix

relenv 0.22.18 rewrote this wrapper to introspect pip's actual install() signature at patch time (inspect.signature + sig.bind_partial) and forward whatever arguments it finds, instead of assuming a fixed shape. Straight from relenv's own source (0.22.22):

Ensure installs honor the TARGET home directory, staying compatible with whatever shape pip's InstallRequirement.install currently has (pip has changed this signature several times across releases, most recently adding script_executable in pip 26.2).

This PR bumps to the latest available release, 0.22.22, which includes this fix plus incidental improvements since 0.22.14 -- notably a fix for onedir entry points on macOS clobbering the caller's cwd when resolving symlinks (relenv#293).

Verification

Downloaded and diffed both sdists directly (0.22.14 vs 0.22.22): only relenv/{common,runtime,pyversions,python-versions.json} differ. All changes are additive -- new supported Python patch versions, a build-metadata platform-tag fix, the introspection-based install wrapper, and the macOS cwd fix. No removed functionality.

Change scope

relenv_version in cicd/shared-gh-workflows-context.yml is the single source of truth tools/pkg/build.py falls back to when no explicit version is passed. The explicit relenv-version: "0.22.14" overrides in ci.yml/nightly.yml/staging.yml/scheduled.yml (12 occurrences) are rendered from .github/workflows/templates/*.yml.jinja -- these were regenerated via tools pre-commit workflows generate-workflows rather than hand-edited, so they stay in sync with the template source instead of drifting from it.

Test plan

  • CI Deps jobs pass on this PR across all platforms.
  • Onedir build/package jobs (which use the pinned relenv-version explicitly) complete successfully with 0.22.22.

🤖 Generated with Claude Code

relenv 0.22.14 (currently pinned) monkeypatches pip's
InstallRequirement.install() with a hardcoded wrapper signature
(branching on argument count: 7/8/9/other). When pip itself adds a
new parameter to install()'s real signature -- most recently
`script_executable` in pip 26.2 -- and pip's own internal caller
starts passing it, that call lands on relenv's wrapper instead (since
relenv replaced the method), whose hardcoded signature doesn't know
about the new parameter:

    TypeError: InstallRequirement.install() got an unexpected
    keyword argument 'script_executable'

relenv 0.22.18 rewrote this wrapper to introspect pip's actual
install() signature at patch time (inspect.signature +
sig.bind_partial) and forward whatever arguments it finds, instead of
assuming a fixed shape. This is documented in relenv's own source:

    "Ensure installs honor the TARGET home directory, staying
    compatible with whatever shape pip's InstallRequirement.install
    currently has (pip has changed this signature several times
    across releases, most recently adding `script_executable` in
    pip 26.2)."

Bumping to the latest available release (0.22.22) picks up this fix
plus incidental improvements since 0.22.14, notably a fix for onedir
entry points on macOS clobbering the caller's cwd when resolving
symlinks (relenv#293). Diffed both sdists directly: only
relenv/{common,runtime,pyversions,python-versions.json} differ, all
additive (new supported Python patch versions, a build-metadata
platform-tag fix, the introspection-based install wrapper, and the
macOS cwd fix) -- no removed functionality.

`relenv_version` in cicd/shared-gh-workflows-context.yml is the
single source of truth tools/pkg/build.py falls back to; the explicit
`relenv-version: "0.22.14"` overrides in ci.yml/nightly.yml/
staging.yml/scheduled.yml were regenerated from their .jinja
templates via `tools pre-commit workflows generate-workflows` rather
than hand-edited, so they stay in sync with the template source.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@charzl
charzl requested a review from a team as a code owner August 21, 2026 21:17
@charzl charzl changed the title Upgrade relenv from 0.22.14 to 0.22.22 [Draft]Upgrade relenv from 0.22.14 to 0.22.22 Aug 21, 2026
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
relenv changed which Python 3.14 patch release it builds/publishes
somewhere between 0.22.18 and 0.22.20 -- 3.14.6 (still published as
of 0.22.18) was replaced by 3.14.7 (published from 0.22.20 onward,
confirmed via the v0.22.22 GitHub release's asset list). This wasn't
caught by diffing the two sdists' python-versions.json, which only
showed 3.14.7 being *added*, not 3.14.6's build assets being dropped
from new releases.

With relenv bumped to 0.22.22 but python_version still pinned to
3.14.6, `relenv fetch --python=3.14.6` 404s on every platform --
that version's native runtime tarball is no longer published for
this relenv release:

    HTTP Error 404: Not Found
    Unable to find file on any hosts: github.com packages.broadcom.com woz.io

Confirmed via the actual release assets: v0.22.22 publishes
3.14.7-*.tar.xz for every platform, no 3.14.6-*.tar.xz.

Regenerated via `tools pre-commit workflows generate-workflows`
(same as the relenv_version bump) rather than hand-edited, so the
generated workflow YAMLs stay in sync with their .jinja templates.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant