Refactor: move get_locked() from VersionSolver to Provider #6204
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refactoring is motivated by #6131. While the change in #6131 seems to be functionally correct, I don't like it from an architectural point of view (passing a
get_locked
fromVersionSolver
toProvider
). However, for the fixProvider
has to know about locked packages. After careful consideration, I came to the conclusion that it makes more sense, ifProvider
provides theget_locked
method sinceProvider
already has different methods that take a dependency as input and give one ore more packages. Further, it already has knowledge about installed packages so it makes sense to extend that to locked packages.To put it in a nutshell, the main objective of this PR is to move
get_locked()
fromVersionSolver
toProvider
. On the way, I noticed some other shortcomings I changed in separate commits.In case anyone is wondering why the
installed
andlocked
fixtures intest_solver
can't be used anymore: SinceProvider
transforms the list of locked packages into a dict, changes to the list of locked packages after creating aProvider
instance have no effect. Since changing locked packages after creating the solver/provider is no real use case (was only done in tests), I decided to adapt the tests in favor of a more clear interface that fits better to the real world use case.