feat(resolver): add download method to all resolver classes#1235
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThis PR replaces resolver Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
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 |
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 `@src/fromager/packagesettings/_resolver.py`:
- Around line 300-301: The download_kind field in the resolver settings is now
required but existing pypi-download configs may omit it, so either give it a
backward-compatible default in the relevant resolver settings class or treat
this as an intentional config break and document it with a versionchanged note
in the class docstring. Update the field definition in the package settings
resolver so loading configs that don’t specify download_kind continues to work,
or clearly signal the breaking change if compatibility is not preserved.
In `@tests/test_packagesettings_resolver.py`:
- Around line 302-315: The resolver test coverage is missing the `download_kind:
sdist` execution path, so `download()` is never verified to dispatch through
`download_sdist` instead of the tarball helper. Add a new test alongside
`test_download` that configures the resolver with `download_kind: sdist`,
patches `fromager.downloads.download_sdist`, and asserts the returned path/kind
plus the expected call arguments. Use the existing `download()` method and
`_parse()` setup to keep the new case aligned with the current resolver tests.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 881e8a75-c367-4165-807e-7dc692fd2e20
📒 Files selected for processing (2)
src/fromager/packagesettings/_resolver.pytests/test_packagesettings_resolver.py
rd4398
left a comment
There was a problem hiding this comment.
Overall looks good. I added couple of comments / suggestions
Add `_download()` to `AbstractResolver` that dispatches to the appropriate download helper based on a mandatory `download_kind` argument. Each concrete resolver implements a public `download()` that delegates with its specific `DownloadKind`. - `PyPIDownloadResolver` accepts `download_kind` as a mandatory Pydantic field (restricted to `sdist | tarball`) - `NotAvailableResolver` and `AbstractHookResolver` override `download()` to raise explicitly - Replace the old `download_kind` ClassVar with a `download_kinds` frozenset ClassVar describing which kinds each resolver can return - Replace `resolves_prebuilt_wheel` property with a ClassVar - Validate `download_kind` against `download_kinds` in `_download()` Co-Authored-By: Claude <claude@anthropic.com> Signed-off-by: Christian Heimes <cheimes@redhat.com>
rd4398
left a comment
There was a problem hiding this comment.
This looks good! Thank you
|
Tick the box to add this pull request to the merge queue (same as
|
Pull Request Description
What
Add
_download()toAbstractResolverthat dispatches to theappropriate download helper based on a mandatory
download_kindargument. Each concrete resolver implements a public
download()that delegates with its specific
DownloadKind.PyPIDownloadResolveracceptsdownload_kindas a mandatoryPydantic field (restricted to
sdist | tarball)NotAvailableResolverandAbstractHookResolveroverridedownload()to raise explicitlydownload_kindClassVar with adownload_kindsfrozenset ClassVar describing which kinds each resolver can return
resolves_prebuilt_wheelproperty with a ClassVardownload_kindagainstdownload_kindsin_download()Why
Include the download logic in the resolver.