fix(pipx): upgrade shared pip for release age installs#10472
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughWhen Changespipx upgrade-shared for minimum_release_age
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR fixes a chicken-and-egg bootstrap failure that occurred when
Confidence Score: 5/5Safe to merge — the upgrade-shared step is best-effort and isolated to the per-tool PIPX_HOME, so a failure leaves behaviour identical to today. The change is narrowly scoped: it only fires on the pipx fallback path when No files require special attention. Important Files Changed
Reviews (5): Last reviewed commit: "test(pipx): drop unnecessary fake system..." | Re-trigger Greptile |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/backend/pipx.rs (1)
296-311: ⚡ Quick winConsider making the upgrade-shared step fully non-fatal.
The
.await?on line 306 will still propagate errors frompipx_cmdcreation (e.g., config/toolset issues), aborting the install. Only errors from.execute()are caught and logged. Since the PR objectives describe this as ensuring pip is "current enough" and the error is logged at debug level, the intent appears to be a best-effort upgrade that should never block the main install.If you want to make this truly non-fatal, wrap both the command creation and execution:
if let Err(err) = async { Self::pipx_cmd( &ctx.config, &["upgrade-shared"], self, &tv, &ctx.ts, ctx.pr.as_ref(), ) .await? .execute() } .await { debug!("failed to upgrade pipx shared libraries before install: {err:#}"); }Alternatively, if config/toolset errors during upgrade-shared should abort the install (because they'd likely cause the main install to fail anyway), the current approach is reasonable.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/backend/pipx.rs` around lines 296 - 311, The upgrade-shared step currently has a `.await?` after the `pipx_cmd` call that will propagate errors from command creation, aborting the install. Only errors from `.execute()` are caught and logged. To make this truly non-fatal as intended (since it's logged at debug level and meant as a best-effort upgrade), wrap both the `Self::pipx_cmd()` creation and the `.execute()` call together in an async block so that all errors—whether from command creation or execution—are caught and logged together rather than propagating the `.await?` error.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/backend/pipx.rs`:
- Around line 296-311: The upgrade-shared step currently has a `.await?` after
the `pipx_cmd` call that will propagate errors from command creation, aborting
the install. Only errors from `.execute()` are caught and logged. To make this
truly non-fatal as intended (since it's logged at debug level and meant as a
best-effort upgrade), wrap both the `Self::pipx_cmd()` creation and the
`.execute()` call together in an async block so that all errors—whether from
command creation or execution—are caught and logged together rather than
propagating the `.await?` error.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 954f7cb5-30c6-4c65-9e86-ade060c3beb5
📒 Files selected for processing (2)
docs/dev-tools/backends/pipx.mdsrc/backend/pipx.rs
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@e2e/backend/test_pipx_minimum_release_age`:
- Line 2: The test script uses jq on line 34 but only declares python3 as a
required command at the beginning of the file. Add a require_cmd jq call near
the existing require_cmd python3 declaration to explicitly declare jq as a
required test dependency. This ensures the test fails immediately with a clear
diagnostic message if jq is not available, rather than failing later during
execution.
- Around line 5-11: The test script attempts to write a fake pipx script to
$HOME/bin/pipx without ensuring that the $HOME/bin directory exists first, which
will cause the test to fail in clean environments. Add a mkdir -p command to
create the $HOME/bin directory before the cat command that writes the fake pipx
script content between the EOF markers.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 08f29b6b-33f9-4218-af91-f260424e0c96
📒 Files selected for processing (2)
e2e/backend/test_pipx_minimum_release_agesrc/backend/pipx.rs
💤 Files with no reviewable changes (1)
- src/backend/pipx.rs
|
@coderabbitai resume |
✅ Action performedReviews resumed. |
Summary
pipx upgrade-sharedbefore pipx fallback installs that forwardminimum_release_ageto pip--uploaded-prior-tois handled by pip, not uvBackground
pipx forwards
pipx install--pip-argsinto shared-library bootstrap (pip install --upgrade pip>=23.1), not just the package install. When mise passes--pip-args=--uploaded-prior-to=..., bootstrap pip (from ensurepip) may not understand that flag and shared pip never upgrades successfully.This is the same chicken-and-egg class of bug as pypa/pipx#544 (install
pip_argsbreaking shared pip upgrade with flags the bootstrap pip does not support). There is no open pipx issue specifically for--uploaded-prior-to; upstream discussion is mostly pypa/pipx#1811 / #1801.Prior mise work on this area:
install_before/ release-age cutoff to pipx and uvRunning
pipx upgrade-sharedfirst (without release-age flags) makes shared pip valid so the subsequentpipx installshared_libs.create()is a no-op and--uploaded-prior-toonly applies to the package install.Related reports: discussion #10088, discussion #10484.
Reproduction
Reproduced with an isolated
PIPX_HOMEby downgrading pipx's shared pip topip==25.3, then running:That failed with
no such option: --uploaded-prior-to. Runningpipx upgrade-sharedfirst upgraded shared pip, and the same install then succeeded.Testing
mise x cargo -- cargo fmt --checkFull local tests were not run.
Discussion
Summary by CodeRabbit
pipxinstalls with release date constraints: whenminimum_release_age/limits apply, mise now attempts to upgradepipx’s shared pip environment before runningpipx install, so pip options such as--uploaded-prior-towork as expected.pipx“minimum_release_age” guidance to reflect the upgrade-first behavior, removing the need for manual Python/pip compatibility prerequisites.pipxminimum release age flow to verify the shared pip environment behavior.