Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughMultiple dependency versions in Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
|
RustPython is a binary and a library. Library user uses Cargo.toml and application uses uses Cargo.lock. Specifying the latest version is good for application users, but not for library users |
That's a good point. |
|
When I originally gave the approval, I hadn't considered the library users. Thinking back on it, it's actually normal behavior for Dependabot to only update Cargo.lock in that regard. For the sake of library users, we need to use the most generous (lowest) version possible, as long as it doesn't affect functionality. So, honestly, I'm leaning toward sticking with the current approach. In the case of something like |
I didn't think in RustPython-as-library side when I approved.
|
@ShaharNaveh choosing tight versions for Cargo.lock and loose versions for Cargo.toml is a good trade-off and consistent. If we have to really upgrade incompatible, they are being upgraded together. |
When deps don't specify their minor version dependabot only update
Cargo.lock(see #7470 for example).This PR ensures that dependabot updates
Cargo.tomlas well.Closes #7470
Summary by CodeRabbit