Introduce /upgrade-pylib-next
#6827
Conversation
📝 WalkthroughWalkthroughThree new Claude command documents added to guide test failure investigation and Python library upgrades. The first provides structured debugging procedures for failing tests. The second automates selection of next upgrade candidates. The third substantially restructures the upgrade workflow with expanded guidance for test management and git workflows. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
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 |
.claude/commands/upgrade-pylib.md
Outdated
| - **Test assertion failure** → `@unittest.expectedFailure` with `# TODO: RUSTPYTHON` comment | ||
| - **Panic/crash** → `@unittest.skip("TODO: RUSTPYTHON; <panic message>")` | ||
| - **Class-specific markers**: If a test fails only in the C implementation (TestCFoo) but passes in the Python implementation (TestPyFoo), or vice versa, add the marker to the specific subclass, not the base class: | ||
| 3. **Mark remaining test failures with auto-mark** |
There was a problem hiding this comment.
quick now auto-mark newly added failing tests. only regressions are remained failing.
Before step 3, let's add review the failing tests and analyze If that's justified to mark failure or not.
Lots of them will be better to report issue or worth to try fix them; otherwise upgrade the dependency lib first.
There was a problem hiding this comment.
I'm dogfooding this command, and as your suggestion, it fixes a failed test automatically!
(Other tests (snippets) seem to fail but anyway 😅)
There was a problem hiding this comment.
Great, it is good as long as it doesn't blindly mark everything expectedFailure
cb9edb5 to
eb416e9
Compare
273678f to
fc57173
Compare
fc57173 to
50abeca
Compare
This pull request updates `types` module to v3.14.2. While doing it, it fixes also async-related feature. This pull request's base is generated by #6827. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Generators that act as iterable coroutines are now recognized as awaitable, improving async behavior. * Yield-from and await interactions now handle coroutine-iterable sources more consistently. * **Bug Fixes** * Reduces spurious TypeError cases when awaiting or yielding from wrapped coroutine-like generators. <sub>✏️ Tip: You can customize this high-level summary in your review settings.</sub> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
23e2a99 to
d24423b
Compare
d24423b to
2783211
Compare
2783211 to
01c614d
Compare
|
Can we merge this pull request? I haven't been able to do much dogfooding these past few days, but I still find it useful. cc #6833 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.claude/commands/upgrade-pylib.md:
- Around line 110-120: Update the fenced "Example Usage" code block to include a
language identifier so syntax highlighting is applied; specifically add "bash"
after the opening triple backticks for the block that contains the
/upgrade-pylib usage examples (lines showing "/upgrade-pylib inspect",
"/upgrade-pylib json", "/upgrade-pylib asyncio" and the path examples) so the
block begins with ```bash instead of ```; no other changes to the content are
needed.
- Around line 51-71: Step 3's markdown code blocks lack language identifiers;
update the code fences around the shell commands in the “Investigate test
failures with subagent” section to use ```bash (or ```sh) for the three examples
containing the commands `cargo run --release -- scripts/update_lib deps
$ARGUMENTS`, `cargo run --release -- -m test test_xxx test_yyy ... 2>&1 | grep
-E "^(FAIL|ERROR):"`, and the example `cargo run --release -- -m test test_bdb
test_inspect test_linecache test_traceback test_zipimport 2>&1 | grep -E
"^(FAIL|ERROR):"` so they render with proper syntax highlighting.
- Around line 1-3: The allowed-tools header currently permits only Bash(git
add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), and
Bash(python3 scripts/update_lib auto-mark:*), but the workflow runs cargo run
--release -- scripts/update_lib deps; update the allowed-tools header to also
include Bash(python3 scripts/update_lib deps:*) (or the equivalent pattern used
for quick/auto-mark) so the `deps` subcommand is allowed; ensure the new entry
matches the existing pattern for `quick` and `auto-mark` to permit the deps
invocation and related test commands.
| --- | ||
| allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), Bash(python3 scripts/update_lib auto-mark:*) | ||
| --- |
There was a problem hiding this comment.
Add missing deps subcommand to allowed-tools.
The workflow in step 3 (line 54) uses cargo run --release -- scripts/update_lib deps, but the allowed-tools header only permits quick and auto-mark subcommands. This will cause the command to be blocked during execution.
🔧 Proposed fix
---
-allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), Bash(python3 scripts/update_lib auto-mark:*)
+allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), Bash(python3 scripts/update_lib auto-mark:*), Bash(cargo run:*)
---Note: This allows cargo run for both the deps command (line 54) and the test execution commands (lines 59, 63).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| --- | |
| allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), Bash(python3 scripts/update_lib auto-mark:*) | |
| --- | |
| --- | |
| allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(python3 scripts/update_lib quick:*), Bash(python3 scripts/update_lib auto-mark:*), Bash(cargo run:*) | |
| --- |
🤖 Prompt for AI Agents
In @.claude/commands/upgrade-pylib.md around lines 1 - 3, The allowed-tools
header currently permits only Bash(git add:*), Bash(git commit:*), Bash(python3
scripts/update_lib quick:*), and Bash(python3 scripts/update_lib auto-mark:*),
but the workflow runs cargo run --release -- scripts/update_lib deps; update the
allowed-tools header to also include Bash(python3 scripts/update_lib deps:*) (or
the equivalent pattern used for quick/auto-mark) so the `deps` subcommand is
allowed; ensure the new entry matches the existing pattern for `quick` and
`auto-mark` to permit the deps invocation and related test commands.
| 3. **Investigate test failures with subagent** | ||
| - First, get dependent tests using the deps command: | ||
| ``` | ||
| cargo run --release -- scripts/update_lib deps $ARGUMENTS | ||
| ``` | ||
| - Look for the line `- [ ] $ARGUMENTS: test_xxx test_yyy ...` to get the direct dependent tests | ||
| - Run those tests to collect failures: | ||
| ``` | ||
| cargo run --release -- -m test test_xxx test_yyy ... 2>&1 | grep -E "^(FAIL|ERROR):" | ||
| ``` | ||
| - For example, if deps output shows `- [ ] linecache: test_bdb test_inspect test_linecache test_traceback test_zipimport`, run: | ||
| ``` | ||
| cargo run --release -- -m test test_bdb test_inspect test_linecache test_traceback test_zipimport 2>&1 | grep -E "^(FAIL|ERROR):" | ||
| ``` | ||
| - For each failure, use the Task tool with `general-purpose` subagent to investigate: | ||
| - Subagent should follow the `/investigate-test-failure` skill workflow | ||
| - Pass the failed test identifier as the argument (e.g., `test_inspect.TestGetSourceBase.test_getsource_reload`) | ||
| - If subagent can fix the issue easily: fix and commit | ||
| - If complex issue: subagent collects issue info and reports back (issue creation on user request only) | ||
| - Using subagent prevents context pollution in the main conversation | ||
There was a problem hiding this comment.
Add language identifiers to code blocks in step 3.
Multiple code blocks in the test failure investigation step are missing language specifications, which reduces readability and prevents syntax highlighting.
📝 Proposed fix
3. **Investigate test failures with subagent**
- First, get dependent tests using the deps command:
- ```
+ ```bash
cargo run --release -- scripts/update_lib deps $ARGUMENTS
```
- Look for the line `- [ ] $ARGUMENTS: test_xxx test_yyy ...` to get the direct dependent tests
- Run those tests to collect failures:
- ```
+ ```bash
cargo run --release -- -m test test_xxx test_yyy ... 2>&1 | grep -E "^(FAIL|ERROR):"
```
- For example, if deps output shows `- [ ] linecache: test_bdb test_inspect test_linecache test_traceback test_zipimport`, run:
- ```
+ ```bash
cargo run --release -- -m test test_bdb test_inspect test_linecache test_traceback test_zipimport 2>&1 | grep -E "^(FAIL|ERROR):"
```📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 3. **Investigate test failures with subagent** | |
| - First, get dependent tests using the deps command: | |
| ``` | |
| cargo run --release -- scripts/update_lib deps $ARGUMENTS | |
| ``` | |
| - Look for the line `- [ ] $ARGUMENTS: test_xxx test_yyy ...` to get the direct dependent tests | |
| - Run those tests to collect failures: | |
| ``` | |
| cargo run --release -- -m test test_xxx test_yyy ... 2>&1 | grep -E "^(FAIL|ERROR):" | |
| ``` | |
| - For example, if deps output shows `- [ ] linecache: test_bdb test_inspect test_linecache test_traceback test_zipimport`, run: | |
| ``` | |
| cargo run --release -- -m test test_bdb test_inspect test_linecache test_traceback test_zipimport 2>&1 | grep -E "^(FAIL|ERROR):" | |
| ``` | |
| - For each failure, use the Task tool with `general-purpose` subagent to investigate: | |
| - Subagent should follow the `/investigate-test-failure` skill workflow | |
| - Pass the failed test identifier as the argument (e.g., `test_inspect.TestGetSourceBase.test_getsource_reload`) | |
| - If subagent can fix the issue easily: fix and commit | |
| - If complex issue: subagent collects issue info and reports back (issue creation on user request only) | |
| - Using subagent prevents context pollution in the main conversation | |
| 3. **Investigate test failures with subagent** | |
| - First, get dependent tests using the deps command: |
🧰 Tools
🪛 LanguageTool
[style] ~68-~68: Consider using a different verb for a more formal wording.
Context: ...getsource_reload`) - If subagent can fix the issue easily: fix and commit - I...
(FIX_RESOLVE)
🪛 markdownlint-cli2 (0.20.0)
[warning] 53-53: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 58-58: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 62-62: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @.claude/commands/upgrade-pylib.md around lines 51 - 71, Step 3's markdown
code blocks lack language identifiers; update the code fences around the shell
commands in the “Investigate test failures with subagent” section to use ```bash
(or ```sh) for the three examples containing the commands `cargo run --release
-- scripts/update_lib deps $ARGUMENTS`, `cargo run --release -- -m test test_xxx
test_yyy ... 2>&1 | grep -E "^(FAIL|ERROR):"`, and the example `cargo run
--release -- -m test test_bdb test_inspect test_linecache test_traceback
test_zipimport 2>&1 | grep -E "^(FAIL|ERROR):"` so they render with proper
syntax highlighting.
| ## Example Usage | ||
| ``` | ||
| # Using module names (recommended) | ||
| /upgrade-pylib inspect | ||
| /upgrade-pylib json | ||
| /upgrade-pylib asyncio | ||
|
|
||
| # Using library paths (alternative) | ||
| /upgrade-pylib cpython/Lib/inspect.py | ||
| /upgrade-pylib cpython/Lib/json/ | ||
| ``` |
There was a problem hiding this comment.
Add language identifier to example usage code block.
The example usage code block is missing a language specification.
📝 Proposed fix
## Example Usage
-```
+```bash
# Using module names (recommended)
/upgrade-pylib inspect
/upgrade-pylib json
/upgrade-pylib asyncio
# Using library paths (alternative)
/upgrade-pylib cpython/Lib/inspect.py
/upgrade-pylib cpython/Lib/json/
</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
## Example Usage
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 111-111: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In @.claude/commands/upgrade-pylib.md around lines 110 - 120, Update the fenced
"Example Usage" code block to include a language identifier so syntax
highlighting is applied; specifically add "bash" after the opening triple
backticks for the block that contains the /upgrade-pylib usage examples (lines
showing "/upgrade-pylib inspect", "/upgrade-pylib json", "/upgrade-pylib
asyncio" and the path examples) so the block begins with ```bash instead of ```;
no other changes to the content are needed.
This pull request introduces
/upgrade-pylib-nextcommand to find a module to update by runningscripts/update_lib todo(#6823). It just finds a module to update and delegates other to/upgrade-pylib. (cc #6580)This pull request also has changes about
/upgrade-pylib. It became to useauto-marksubcommand to test newly introduced tests also.Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.