Dynamische Dependencies / Umfassende Dependency-Resolution #196
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ManifestFactory isn't available in the class scope.
It was the only route not using it.
…_manifest_from_location
Instead of dir_name, specify NS, SN and version. The dir name will later be built on the fly. Add transitive dependencies so that a complete dependency tree can be built without retrieving manifest of the statically packaged dependency.
Overriding `version: str` with the incompatible `semver.Version` type breaks the Liskov substitution principle and leads to problems when trying to write code that supports both `Manifest` and `PackageConfig`.
resolve_dependency_tree is intended to also be usable by the SDK when validating and locking the dependency tree.
This led to an unhelpful InconsistentCandidate error before.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Der handgeschriebenen Algorithmus, den ich in einem der letzten Meetings letztes Jahr erwähnt hatte, war zwar schön und hätte viele Fälle korrekt berechnet, ich bin aber doch noch auf Edge-Cases gestoßen, die damit nicht sinnvoll zu lösen waren. Stattdessen habe ich jetzt zu resolvelib, die auch von pip verwendet wird, gegriffen. Das macht die Implementierung nicht weniger kompliziert, aber dafür richtig :)
Kurzer Abriss zu resolvelib:
RT(Den Requirement-Typen),CT(Den Lösungskandidat-Typen) undKT(den Identifier Typen)RTist bei unsDynamicRequirement | StaticRequirement | RootRequirementAndCandidate, wobei die ersteren beiden nur Wrapper umDistDynamicQPyDependencybzw.DistStaticQPyDependencymit schönem__str__sind.CTist bei unsDynamicCandidate | StaticCandidate | RootRequirementAndCandidate, wobei die ersteren beiden Aliase der neuen KlassenDynamicDependencySolutionundStaticDependencySolutionsind, die inquesionpy_commonleben, weil sie auch ans Paket geschickt werden.KTist bei unsPackageNamespaceAndShortNameQPyResolvelibProviderimplementiert alle domänenspezifische Funktionalität, die resolvelib braucht:identifygibt bei uns ganz trivial die NSSN zurückget_preferenceist eine Heuristik und gibt für je ein Paket einen Sort-Key zurück, der dafür sorgt, dass stärker eingeschränkte Pakete zuerst resolved werden. (z.B. statische Dependency vor@local/dep_a == 1.2.3vor@local/dep_b ^= 1.0.0vor@local/dep_c)find_matchesfindet für ein Paket (NSSN) alle Lösung, die die bisher gefundenen Requirements erfüllen, geordnet von der "besten" (neusten) zur "schelchtesten" (ältesten).is_satisfied_byprüft, ob ein irgendwann bereits von `find_matches) gefundener Kandidat das gegebene (vllt. neue) Requirement erfüllt.get_dependenciesgibt die transitiven Dependencies einesCandidates zurück, wickelt bei uns also einfachDynamicRequirement/StaticRequirementum dieDistQPyDependencyQPyResolvelibReporterwird bei den einzelnen Schritten im resolvelib-Algorithmus informiert. Ich mache damit zwei Dinge:MAX_QPY_DEPENDENCY_LEVELSüberschritten wurde. (Das ist vermutlich nicht ganz so gedacht, aber pragmatisch.)(Zu
RootRequirementAndCandidate: Das Root-Paket muss extra abgebildet werden, weil resolvelib sonst keine Konflikte damit erkennen kann. Da es genau ein Root-Requirement und einen ihm gleichen Root-Kandidaten gibt, benutze ich eine Klasse für beides.)Erwähnenswert ist vielleicht auch, dass ein
DynamicRequirementdurchaus durch einenStaticCandidategelöst werden kann, wenn ein anderes Paket diese statische Dependency hat und die beiden sich nicht widersprechen.Die Implementierung des resolvelib-Providers und -Reporters, sowie eine kleine Wrapper-Funktion liegen in
questionpy_server.dependencies._solver. Das ist explizit so gedacht, dass es sowohl vom Server beim Ausführen als auch vom SDK beim Bauen (und Ausführen) verwendet werden kann.Da sich die
PackageCollectionaus dem Server nicht wirklich für's SDK eignet, ist die Paket-Abfrage selbst in der ABCDynamicDependencyResolverabstrahiert.Bei Worker-Start werden nach der Auflösung des Baumes für alle ausgewählten Lösungen die
PackageLocationsgeholt, und in derLoadQPyPackage-Nachricht an den Worker geschickt. An der Logik im Worker hat sich nicht super viel verändert, nur werden Pakete jetzt nicht mehr rekursiv geöffnet, sondern in umgekehrter topologischer Sortierung.TODO
Die Lock-Informationen, die vom SDK jetzt schon geschrieben werden, auch verwenden. Angesichts der Zeit habe ich das jetzt außen vor gelassen.