search

questionpy-org / questionpy-sdk

Library and toolset for the development of QuestionPy packages
https://questionpy.org
MIT License
0 stars 2 forks source link

Im Manifest Dateien des Pakets inkl. MIME-Type speichern #84

Closed MartinGauk closed 4 months ago

MartinGauk commented 4 months ago

Wir hatten überlegt, dass wir im Manifest alle Dateien des Pakets (jedenfalls im dist Ordner) im Manifest aufführen sollten zusammen mit dem MIME-Type. Der Sinn dahinter ist vor allem, dass dem LMS leicht die static Dateien bekannt gemacht werden können und es generell Klarheit über die MIME-Types gibt. Die Dateigröße ist sicherlich auch sinnvoll.

Den MIME-Type können wir durch file ermitteln lassen.

tumidi commented 4 months ago

Wir hatten überlegt, dass wir im Manifest alle Dateien des Pakets (jedenfalls im dist Ordner) im Manifest aufführen sollten zusammen mit dem MIME-Type.

Ich verstehe dich so, dass während des Build-Prozesses des Pakets eine Liste mit Dateien geführt wird, die ins Zip-File (dist-Ordner) geschrieben werden. Abschließend soll diese Liste dann ins Manifest geschrieben werden.

Das wäre mit der aktuellen Klassenhierarchie nicht zu vereinbaren, denke ich.

Aktuell erbt questionpy_sdk.models.PackageConfig von questionpy_common.manifest.Manifest. Wenn wir Manifest nun Felder hinzufügen, die nur nach dem Build-Prozess vorhanden sind, müssten wir dem irgendwie Rechnung tragen.

Also z.B. ManifestDist erbt von Manifest. ManifestDist wäre neu und beinhaltet zusätzliche Felder, die der Build-Prozess hinzufügt. questionpy-server würde dann zukünftig mit ManifestDist anstatt Manifest arbeiten. (Gäbe natürlich noch andere Möglichkeit das zu modellieren, z.B. Composition.)

Ich denke, das Ganze zeigt nur ein Problem auf, welches uns früher oder später eh beißen würde: DirBasedPackage aus dem Server erwartet ein Manifest. Das würde zukünftig mit ManifestDist nicht mehr funktionieren, da ja ein Package-Verzeichnis noch nicht gebaut ist. (Dasselbe gilt aber auch für andere Build-Artefakte, die bspw. per Build-Hooks gebaut werden.)

Wie weiter vorgehen?

  1. Das SDK baut wahlweise direkt ins dist-Verzeichnis (anstatt .qpy-Datei).
    Das SDK sollte die Möglichkeit bieten, direkt ins dist-Verzeichnis des Quellverzeichnisses zu bauen. Das sollte wahrscheinlich auch noch durch ein watch-Kommando ergänzt werden, welches das Quellverzeichnis überwacht und bei file changes automatisch baut.
    Ein DirBasedPackage ist nur dann valide, wenn es ein fertig gebautes dist beinhaltet.

  2. Das "Paket-Bauen" wird Teil des Servers.
    Die Logik zum Paket-Bauen lebt im Server. Dann könnte DirBasedPackage tatsächlich ein Quellverzeichnis meinen.

Ich tendiere zu 1., denn ich denke, das Bauen von Paketen (und generell entwicklungsbezogene Aufgaben) sollten nicht im Server, sondern im SDK leben. ~Evtl. ist DirBasedPackage schon eine Verletzung dieses Grundsatzes, denn DirBasedPackage hat ja neben Entwicklung erst mal keine andere Existenzberechtigung (oder?). Evtl. wäre es sogar möglich und auch sauberer, DirBasedPackage (oder die Logik dahinter) ganz aus dem Server herauszuhalten und ins SDK zu verschieben?~ Nein, weil später qpy-Pakete potentiell entpackt werden irgendwo....

tumidi commented 4 months ago

Den MIME-Type können wir durch file ermitteln lassen.

Meinst du das Kommando GNU file? file ist ja nicht portable, also existiert nicht unter Windows ohne WSL oder ähnliches. Daher müsste man libmagic nehmen (also die lib auf dem das file-Kommando basiert), z.B. in Form von python-magic.

Es gibt auch das mimetypes-Modul aus der Python Standard Lib, allerdings rät das nur anhand der Dateiendung. Vielleicht wäre das schon ausreichend?

tumidi commented 4 months ago

Wie weiter vorgehen?

MartinGauk commented 4 months ago

Danke für die Zusammenfassung unseres Meetings vorhin. Noch eine kleine Ergänzung, was wir besprochen haben:

Das Manifest wird ergänzt um ein Mapping/dict von str (relativer Pfad zu dist) zu PackageFile.

PackageFile(BaseModel):
+ mime_type: str
+ size: int
tumidi commented 4 months ago

Resolved in 4714958c823ac4090072fd163ee7f5b05725c831