-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix considered python constraint for overrides #10157
fix considered python constraint for overrides #10157
Conversation
Reviewer's Guide by SourceryThis pull request addresses a bug in the solver where the package's effective Python constraint was incorrectly using the root package's constraint even when overrides were applied. The implementation refactors the constraint handling by renaming and recalculating the Python constraint, ensuring that the overrides are properly taken into account. Additionally, tests have been added and updated to validate that the solver now correctly handles transitive Python constraints under override scenarios. Updated Provider Class Diagram for Python Constraint OverridesclassDiagram
class Provider {
- _package_python_constraint : VersionConstraint
- _direct_origin
- _io
- _env : Env | null
- _is_debugging : bool
- _overrides : dict<Package, dict<string, Dependency>>
- _deferred_cache : dict<Dependency, Package>
- _load_deferred
<<cached>>
+ _overrides_marker_intersection : BaseMarker
<<cached>>
+ _python_constraint : VersionConstraint
+ __init__(...)
+ pool() : RepositoryPool
+ use_latest() : Collection<NormalizedName>
+ is_debugging() : bool
+ set_overrides(overrides : dict<Package, dict<string, Dependency>>) : void
+ load_deferred(load_deferred : bool) : void
+ use_environment(env : Env) : Iterator<Provider>
+ use_latest_for(names : Collection<NormalizedName>) : Iterator<Provider>
+ complete_package(...) : void
}
%% Note: The class now properly computes the effective Python constraint using overrides markers.
%% The field _python_constraint is now a cached property that intersects _package_python_constraint
%% with the Python constraint derived from the overrides marker intersection.
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @radoering - I've reviewed your changes - here's some feedback:
Overall Comments:
- Consolidate the repeated logic for renaming and updating python constraints to a single helper to reduce potential inconsistencies.
- Instead of manually deleting cached properties in set_overrides, consider using a more robust cache invalidation strategy with the cached properties.
Here's what I looked at during the review
- 🟡 General issues: 1 issue found
- 🟢 Security: all looks good
- 🟡 Testing: 1 issue found
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
8720feb
to
a5a528a
Compare
@sourcery-ai review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @radoering - I've reviewed your changes - here's some feedback:
Overall Comments:
- Consider renaming _package_python_constraint or the computed _python_constraint property to clarify their roles and avoid confusion.
- Review the cache invalidation in set_overrides to ensure it safely resets the related state without side effects.
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Previously, the Python constraint of the root package has always been used to check for incompatibilities, even if the Python constraint had effectively been restricted by overrides before. This could result in false conflicts à la "The current project's supported Python range is not compatible with some of the required packages Python requirement."
a5a528a
to
0152071
Compare
Previously, the Python constraint of the root package has always been used to check for incompatibilities, even if the Python constraint had effectively been restricted by overrides before. This could result in false conflicts à la "The current project's supported Python range is not compatible with some of the required packages Python requirement."
Pull Request Check List
Resolves an issue introduced (or maybe just revealed) by #10141
Summary by Sourcery
Fix an issue where the root package's Python constraint was always used for incompatibility checks, even when overrides had restricted it, leading to false conflict errors.
Bug Fixes:
Tests: