Statische Dependencies Laden #165
Conversation
| super().__init__(f"'{nssn}'. Dependency stack: {stack}", stack) | ||
|
|
||
|
|
||
| class TooDeeplyNestedDependencyError(Exception): |
There was a problem hiding this comment.
| class TooDeeplyNestedDependencyError(Exception): | |
| class TooDeeplyNestedDependencyError(DependencyError): |
|
|
||
| new_stack = (*stack, nssn) | ||
| for dep_location in package.resolve_static_dependencies(): | ||
| dep_nssn, dep_package = self._open_packages_recursively(msg, dep_location, new_stack) |
There was a problem hiding this comment.
Würde das nicht kaputt gehen, wenn z.B. Paket A zwei Dependencies hat (X und Y v2.0.0) und X hat als Dependency Y v1.0.0, wobei Y v1.0.0 und Y 2.0.0 inkompatibel sind?
Ah, dieser Kommentar müsste vermutlich nur angepasst werden: Es werden aktuell ja keine doppelten Pakete erlaubt, egal welche Version sie haben und wo sie liegen.
| class PackageNotInitializedError(Exception): | ||
| """The packages state was not INITIALIZED.""" | ||
|
|
||
|
|
||
| class PackageNotLoadedError(Exception): | ||
| """The packages state was not LOADED or higher.""" |
There was a problem hiding this comment.
| class PackageNotInitializedError(Exception): | |
| """The packages state was not INITIALIZED.""" | |
| class PackageNotLoadedError(Exception): | |
| """The packages state was not LOADED or higher.""" | |
| class PackageNotInitializedError(Exception): | |
| """The package's state was not INITIALIZED.""" | |
| class PackageNotLoadedError(Exception): | |
| """The package's state was not LOADED or higher.""" |
| if nssn in stack and self._packages[nssn].manifest.version == package.manifest.version: | ||
| raise CircularDependencyError(nssn, stack) |
There was a problem hiding this comment.
Ich denke, diese Erkennung funktioniert nur innerhalb eines einzelnen Paket-Lade-Zyklus, oder? Wenn mehrere Pakete nacheinander geladen werden mittels LoadQPyPackage(...) nicht mehr. Konkretes Beispiel:
LoadQPyPackage(A)
A > B
✔️ (da kein Zyklus im aktuellen stack)
LoadQPyPackage(B)
B > C
✔️ (da kein Zyklus im aktuellen stack)
LoadQPyPackage(C)
C > A
✔️ (da kein Zyklus im aktuellen stack)
❌ TopologicalSorter.static_order() wirft CycleError, da über alle aktuell geladenen self._packages sortiert wird und insgesamt aber A > B > C > A (zyklisch).
Also, müsste static_order() doch noch ein try/catch bekommen, oder?
try:
linearized = _linearize_packages(self._packages)
except CyclicError:
raise CircularDependencyError(...)| class DistStaticQPyDependency(BaseModel): | ||
| name: str | ||
| hash: str |
There was a problem hiding this comment.
Evtl. das noch inline dokumentieren.
Ich hatte naiv erst mal angenommen, es handelt sich bei name um den Package-Namen, bzw. -Specifier. Aber es handelt sich quasi um eine "filename-friendly" Variante, oder?
Vielleicht kann die Generierung des Namens auch direkt in Manifest passieren?
@property
def dirname(self) -> str:
return f"{self.namespace}-{self.short_name}-{self.version}"Oder so ähnlich. Dann muss das SDK hier auch nicht wissen, wie dieser Name zu generieren ist.
Btw, das ließe sich dann auch im SDK Webserver gleich mitverwenden, der generiert auch so einen "dateinamenfreundlichen" Namen hier.
Ich trenne den Lebenszyklus von Paketen jetzt in 2 Schritte. Erst wird ein Paket geöffnet aka prepared, im Falle von ZIP-Paketen geht damit das Entpacken einher. Dann wird das Manifest gelesen und anhand dessen werden alle Dependencies geöffnet (rekursiv). Wenn der gesamte Baum geöffnet wurde, werden alle Pakete linearisiert und initialisiert.
Die Trennung zwischen dem Öffnen und dem Initialisieren der Pakete halte ich an sich für sauber, aber erlaubt auch in Zukunft, dazwischen noch weitere Nachrichten hin-und her zu passen. Beispielsweise könnten dynamische Dependencies mit einer "Ich brauche noch folgende Pakete"-Nachricht vom Worker zum Server geschehen.
Außerdem fallen etwaige Dependency-Konflikte dann auf, bevor irgendein Paket initialisiert wird.
Closes: #158