Conversation
WalkthroughThis pull request updates the dulwich dependency version constraint in the project manifest. The minimum required version was incremented from 0.21.4 to 0.24.7. The change involves a single line modification in pyproject.toml with no alterations to the codebase, public APIs, or control flow logic. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## stable #848 +/- ##
==========================================
- Coverage 80.38% 80.36% -0.03%
==========================================
Files 115 115
Lines 9926 9875 -51
Branches 1515 1504 -11
==========================================
- Hits 7979 7936 -43
+ Misses 1423 1417 -6
+ Partials 524 522 -2
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pyproject.toml (1)
26-26: Consider adding an upper bound<1.0.0to guard against the already-released dulwich 1.x.dulwich 1.1.0 is already published on PyPI (released Feb 17, 2026), so
>=0.24.7allows pip to resolve to the 1.x line today. Since the PR explicitly notes migration to dulwich 1.0 is deferred to a future SDK release, an unguarded lower-bound-only constraint means any fresh install could get 1.x and silently pick up breaking API changes before that migration work is done.📦 Proposed upper bound
- "dulwich>=0.24.7", + "dulwich>=0.24.7,<1.0.0",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pyproject.toml` at line 26, The dependency entry "dulwich>=0.24.7" should be constrained to prevent accidental upgrades to the 1.x line now on PyPI; update the dependency for dulwich to include an upper bound (e.g. change the requirement string referencing "dulwich>=0.24.7" to include "<1.0.0") so new installs will not resolve to dulwich 1.x until an explicit migration is performed.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@pyproject.toml`:
- Line 26: The dependency entry "dulwich>=0.24.7" should be constrained to
prevent accidental upgrades to the 1.x line now on PyPI; update the dependency
for dulwich to include an upper bound (e.g. change the requirement string
referencing "dulwich>=0.24.7" to include "<1.0.0") so new installs will not
resolve to dulwich 1.x until an explicit migration is performed.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
pyproject.toml
2 participants
Why
Since a call we were using within dulwich got deprecated we'd previously switched to the recommended method. However that method didn't exist in previous versions of dulwich. As we allow an earlier version that what is actually pinned within uv.lock this wasn't found during the switch. We'd need to have a proper support matrix where we test a larger range of packages to validate that our range of supported versions are actually valid.
What changed
Note that dulwich 1.0 has been related and we'll probably switch to that in an upcoming release after 1.8.
Summary by CodeRabbit