Paketabhängigkeiten

[MartinGauk]

Hier soll überlegt werden, wie statische und dynamische Abhängigkeiten eines QPy-Pakets zu anderen Paketen behandelt werden sollen.

Was sollen die Abhängigkeiten machen?

• natürlich sollen sie Python-seitig Funktionen bereitstellen können, die vom Hauptpaket aufgerufen werden können
• sie sollen auch statische Dateien wie z.B. JavaScript enthalten können
• z.B. bei dem künftigen Feature "Routes" sollen sie eigene Routes registrieren können

Die letzten beiden Punkte erfordern, dass alle Pakete (auch reine Library-Pakete) eine init Funktion haben. Dafür existiert auch bereits das BasePackageInterface.

Statische Abhängigkeiten

• sind in der ZIP-Datei zusammen mit dem Hauptpaket enthalten, entpackt?
• müssen beim Bauen des Hauptpakets in einem definierten Unterordner liegen
• das questionpy package könnte zu einem QPy-Paket ausgebaut werden und vorerst implizit als statische Abhängigkeit mitpaketiert werden

Dynamische Abhängigkeiten

• werden in der qpy_config.yml definiert und zur Laufzeit vom Application Server geladen
• die statischen und dynamischen Abhängigkeiten können rekursiv weitere dynamische Abhängigkeiten beinhalten?
• die konkreten Abhängigkeiten (Paket und Version) beim Bauen festhalten (im Manifest locken) vs. der Application Server löst sie auf
• eine Abhängigkeit kann auch als "web-only" (oder so ähnlich) definiert werden, d.h. sie wird vom Application Server nicht in den Worker geladen, z.B. MathJax, das einige MB umfasst und im Worker keinen Nutzen hat, da es nur statische Dateien (JS und Fonts) beinhaltet

Implementierungsfragen

• Ist die Reihenfolge relevant, in der das Hauptpaket und die Abhängigkeiten ausgeführt werden (d.h. ihre init Funktionen)?
• IDE: die Abhängigkeiten sollten für die Entwicklung des Hauptpakets so verfügbar gemacht werden können, dass Importe ordentlich funktionieren, sowohl Python als auch JS.
• Das LMS hat die Möglichkeit, "web-only" Pakete auszutauschen, z.B. MathJax wird selber kompatibel bereitgestellt

[MHajoha]

RFC

Statische Dependencies

• Liegen als ZIP-Pakete in dist/dependencies/qpy/. Das Entpacken würde ich, genau wie beim Hauptpaket, fürs Erste erst beim Start machen, da wir ja an einigen Stellen davon ausgehen, dass ein Paket immer einen Hash hat.
• Sollten wir die auch im Manifest listen?

  "dependencies": {  
      "qpy": [  
          {  
              "filename": "local-mystaticpackage-0.1.0.qpy",  
             "hash": "3ef89d1f5ee5757d8a024264caaf445fad49a503b3621dcf94e3fa9abc6e0c3d"  
          }  
      ]
  }

Dynamische Dependencies

• Werden vor Worker-Start durch den Server geladen. Erlaubte Quellen sind RepoCollector und LocalCollector, insb. also nicht der LMSCollector.
• Das programmatische Laden von Paketen (nach Worker-Start) scheint mir gefährlich mit Blick auf Worker-Reuse und würde ich erstmal nicht erlauben. (Auch nicht für statische / gebundelte Pakete, die würde ich immer Laden, wenn sie vorhanden sind.)
• Ich denke wir sollten genistete Abhängigkeiten erlauben, aber die maximale Baumtiefe begrenzen. Vielleicht auch die Anzahl der direkten Dependencies.
• Wir sollten eine Zykluserkennung einbauen.
• Format in der qpy_config.yml:

  dependencies:  
    qpy:  
      - "@myorg/mypackage >= 1.7.0, < 2.0.0" # Vgl. PEP 508
      - # Langfassung
        namespace: myorg  
        short_name: mypackage  
        version: ">= 1.7.0, < 2.0.0" 

Locking

# Write lock versions. If the locked version isn't available at runtime, allow a different version matching the original  
# specifier.  
lock_dependencies: preferred-allow-downgrade

# Write lock versions. If the locked version isn't available at runtime, allow a different version matching the original  
# specifier, IF that version is newer than the locked version. 
lock_dependencies: preferred-no-downgrade

# Write lock versions. If the locked version isn't available at runtime, fail.  
lock_dependencies: required

# Don't write lock versions at all.  
lock_dependencies: no

dependencies:  
  qpy:  
    - namespace: myorg  
      short_name: mypackage  
      version: ">= 1.7.0, < 2.0.0"  
      lock: required # Overrides global option.

Defaults:

• Für type: QUESTIONTYPE ist der Default lock_dependencies: preferred-no-downgrade.
• Für type: LIBRARY ist der Default lock_dependencies: no.
• Dass type: QUESTION dazugekommen ist, sehe ich tatsächlich jetzt erst. Was genau würde das ausdrücken?

Das deckt sich mit der Funktionsweise der meisten Paketmanager.

Manifest-Format

"dependencies": {  
    "qpy": [
        {  
            "namespace": "myorg",  
            "short_name": "mypackage",  
            "version": ">= 1.7.0, < 2.0.0",  
            "locked": "required | preferred-allow-downgrade | preferred-no-downgrade | no",
            "locked_version": "1.7.3",  
            "locked_hash": "998e4b1dd46503c87229340df19e5cb7113edc5a316f63980bb534d6268eb7ac"  
        }
    ]
}

Erklärung:

• namespace, short_name und version: Aus qpy_config.yml übernommen
• locked: Gleiche Bedeutung wie in der qpy_config.yml.
  • Bei Existenz von locked_version und locked_hash wäre der Wert no hier natürlich recht unsinnig, dann würde ich das Locking aber einfach ignorieren.
  • Ist locked nicht no, aber fehlen locked_version oder locked_hash, würde ich einen Fehler werfen, das Paket wäre dann unbrauchbar.
• locked_version: Das bei Packaging neuste Paket, die den Specifier erfüllt
• locked_hash: Paket-Hash desselben

PyPI-Dependencies

Ich würde größere Anpassungen wie insb. dynamische PyPI-Dependencies hier out-of-scope lassen, aber womöglich das Format in der qpy_config.yml anpassen:

dependencies:  
  pypi:  
    - "numpy >=1.0.0, <2.0.0" # PEP 508 (https://packaging.python.org/en/latest/specifications/dependency-specifiers/)

NumPy würde dann aber nach wie vor ins Paket gebundelt werden.

Web-Only-Pakete

• eine Abhängigkeit kann auch als "web-only" (oder so ähnlich) definiert werden, d.h. sie wird vom Application Server nicht in den Worker geladen, z.B. MathJax, das einige MB umfasst und im Worker keinen Nutzen hat, da es nur statische Dateien (JS und Fonts) beinhaltet

Das klingt ganz sinnvoll, wobei ich eher das Paket als web-only (bzw. asset-only) markieren würde, als die Dependency.

• Das LMS hat die Möglichkeit, "web-only" Pakete auszutauschen, z.B. MathJax wird selber kompatibel bereitgestellt

Habe ich prinzipiell nichts gegen, spart uns aber denke ich nur ein paar Aufrufe für ein paar bestimmte Pakete, daher würde ich das erstmal zurückstellen.

Initialisierung

Ich denke wir sollten garantieren, dass ein Paket immer nach seinen Dependencies initialisiert wird. Unter Abhängigkeiten eines Pakets würde ich tendenziell keine Reihenfolge garantieren, dann hätten wir in Zukunft noch die Möglichkeit, das zu parallelisieren.

[MartinGauk]

Statische Dependencies

• Gibt es eigentlich einen (zwingenden) Grund, warum wir von denen noch einen Hash benötigen?
• Hinsichtlich des Umgangs mit statischen Dateien sehe ich bei verschachtelten ZIP-Dateien (eine statische Abhängigkeit enthält wiederum statische Abhängigkeiten und die evtl. auch wieder) Schwierigkeiten, leicht an die Datei zu kommen, die angefordert wird.
• Wäre es auch denkbar/sinnvoll, alle Abhängigkeiten (rekursiv) entpackt in einen Ordner zu stecken?

Dynamische Dependencies

• Das klingt für mich alles sehr sinnvoll.
• Mir gefällt auch das Konzept mit lock_dependencies: preferred-.... Meine Sorge ist ja immer, dass in einer Abhängigkeit eine Sicherheitslücke entdeckt wird und man das eigene Paket mit gelockten Abhängigkeiten nicht updatet. So könnte man überlegen, dass Paketversionen mit bekannten Sicherheitslücken aus dem öffentlichen Repo entfernt werden (oder man führt später noch ein Konzept ein, dass in den Repo-Metadaten diese Versionen aufgelistet werden, die möglichst nicht mehr verwendet werden sollten).
• Allgemein bezüglich des Manifest-Formats: Könnte es hier noch sinnvoll sein, jeweils aufzulisten, welche direkten Abhängigkeiten eine Abhängigkeit hat? Dann könnten wir bei der Initialisierung doch noch eine topologische Sortierung durchführen (später).

Dass type: QUESTION dazugekommen ist, sehe ich tatsächlich jetzt erst. Was genau würde das ausdrücken?

So neu ist das eigentlich nicht. QUESTION ist sehr ähnlich zu QUESTIONTYPE und soll auch nicht anders behandelt werden. Die Idee ist, dass es irgendwann als Filtermöglichkeit zum Suchen nach anderen Paketen genutzt werden könnte. QUESTIONTYPE ist etwas Generisches und lässt sich anpassen. QUESTION ist schon eine fertige/konkrete Frage, die zwar vielleicht in Details noch einzelne Options anbietet, aber keinen allgemeinen Einsatzzweck bietet.

Web-Only-Pakete

Das klingt ganz sinnvoll, wobei ich eher das Paket als web-only (bzw. asset-only) markieren würde, als die Dependency.

Das können wir so machen. Im Manifest müsste diese Info auch noch zu jeder Abhängigkeit hinterlegt werden, damit der Server direkt weiß, was er für den Worker ignorieren kann.

Habe ich prinzipiell nichts gegen, spart uns aber denke ich nur ein paar Aufrufe für ein paar bestimmte Pakete, daher würde ich das erstmal zurückstellen.

Im Falle von MathJax ist das tatsächlich nicht unwichtig, aber hat auch keine Dringlichkeit. Wichtig ist mir zunächst, dass wir es dem LMS nicht konzeptuell erschweren, diese Pakete auszutauschen. ich glaube aber, dass das hier nicht der Fall ist.

[MHajoha]

Statische Dependencies

• Gibt es eigentlich einen (zwingenden) Grund, warum wir von denen noch einen Hash benötigen?

Keinen zwingenden, nein. Aber wir gehen im Code an einigen Stellen davon aus, dass Pakete Hashes haben. Ich vermute, es macht die Implementierung deshalb einfacher, die Deps als ZIPs zu halten. 🤔

• Hinsichtlich des Umgangs mit statischen Dateien sehe ich bei verschachtelten ZIP-Dateien (eine statische Abhängigkeit enthält wiederum statische Abhängigkeiten und die evtl. auch wieder) Schwierigkeiten, leicht an die Datei zu kommen, die angefordert wird.
• Wäre es auch denkbar/sinnvoll, alle Abhängigkeiten (rekursiv) entpackt in einen Ordner zu stecken?

Zur Laufzeit würde ich definitiv den Dependency-Baum in ein flaches Verzeichnis entpacken ((worker_home)/packages), wo aktuell ja schon das Main-Paket entpackt liegt. Datei-Zugriff wäre dann kein Problem mehr.

Was die Paketstruktur betrifft, will allerdings eigentlich daran festhalten, irgendwann Pakete nicht mehr zu entpacken, sondern z.B. https://github.com/google/mount-zip zu verwenden. Da wäre es womöglich problematisch / zu langsam, mehrere Mounts zu haben, die voneinander abhängen. Daher bin ich gerade unentschlossen... Wir könnten beim Bauen ja entpacken, den Hash abspeichern und einfach darauf vertrauen, dass die Dateien sich nicht geändert haben...

Dynamische Dependencies

Mir gefällt auch das Konzept mit lock_dependencies: preferred-.... Meine Sorge ist ja immer, dass in einer Abhängigkeit eine Sicherheitslücke entdeckt wird und man das eigene Paket mit gelockten Abhängigkeiten nicht updatet. So könnte man überlegen, dass Paketversionen mit bekannten Sicherheitslücken aus dem öffentlichen Repo entfernt werden (oder man führt später noch ein Konzept ein, dass in den Repo-Metadaten diese Versionen aufgelistet werden, die möglichst nicht mehr verwendet werden sollten).

Ja, ich denke da könnte man sich von PyPI inspirieren lassen: https://docs.pypi.org/project-management/yanking/

Allgemein bezüglich des Manifest-Formats: Könnte es hier noch sinnvoll sein, jeweils aufzulisten, welche direkten Abhängigkeiten eine Abhängigkeit hat? Dann könnten wir bei der Initialisierung doch noch eine topologische Sortierung durchführen (später).

Die Daten sind ja schon vorhanden, wir müssen dann nur rekursiv die Manifests der Dependencies durchgehen, um einen vollständigen Abhängigkeitsbaum zu generieren. Den schon direkt in's Manifest des Wurzelpakets zu schreiben, hätte natürlich den Vorteil, dass dann alle Dependencies parallel geholt werden könnten. Würde ich aber als Optimierung für die Zukunft lassen ;)

Dass type: QUESTION dazugekommen ist, sehe ich tatsächlich jetzt erst. Was genau würde das ausdrücken?

So neu ist das eigentlich nicht. QUESTION ist sehr ähnlich zu QUESTIONTYPE und soll auch nicht anders behandelt werden. Die Idee ist, dass es irgendwann als Filtermöglichkeit zum Suchen nach anderen Paketen genutzt werden könnte. QUESTIONTYPE ist etwas Generisches und lässt sich anpassen. QUESTION ist schon eine fertige/konkrete Frage, die zwar vielleicht in Details noch einzelne Options anbietet, aber keinen allgemeinen Einsatzzweck bietet.

Dann würde ich QUESTION hier gleich behandeln wie QUESTION_TYPE 👍

[MHajoha]

Ich habe die Arbeit daran jetzt erstmal damit begonnen, das Dep-ZIP zu entpacken, bzw. dessen Inhalt rüberzukopieren.

Dabei fiel mir auf:

• Wollen wir zusätzlich auch erlauben, ein anderes Source-Verzeichnis als statische Dependency zu listen, das wir dann ad-hoc bauen und einpaketieren?
• Ich muss relativ viel an PackageBuilderBase etc. ran. Ich denke es wäre sinnvoll, zunächst Isoliertes Paket-Build-Environment #174 zu lösen, und dann erst hieran weiter zu arbeiten. Wie sieht du das?

[MartinGauk]

Wie sieht du das?

Sehe ich auch so.

Wollen wir zusätzlich auch erlauben, ein anderes Source-Verzeichnis als statische Dependency zu listen, das wir dann ad-hoc bauen und einpaketieren?

Nein, ich denke, dass das nicht notwendig ist.