[Thema]: mob-developing a CLI tool for merging directories (when conflict-free) in Haskell

[das-g]

📝 Beschreibung

Lasst uns Mob-Programming an einem nicht-trivialen aber trotzdem überschaubaren Beispiel üben:

Verzeichnis-Zusammenführung

Aufgabe des zu entwickelnden CLI-Programms

Zweck dieses Programms ist, den Inhalt mehrerer Verzeichnisse zusammenzuführen, sofern das konfliktfrei möglich ist, und ohne Aktion mit informativen Fehlermeldungen (und einem non-zero exit code) abzubrechen, falls nicht.

Das Programm soll die Pfade zu mehrerer zusammenzuführender Dateisystem-Verzeichnissen ("Ordnern") sowie zu einem Ausgabe-Verzeichnis als CLI-Argumente entgegennehmen. Falls es möglich ist, die Inhalte der zusammenzuführenden Verzeichnisse (unter Beibehaltung derer internen Struktur) im Ausgabeverzeichnis verlustfrei (also ohne gegenseitiges Überschreiben) zusammenzukopieren, so soll das Programm dies machen; andernfalls soll es auf der Kommandozeile ausgeben, wieso das nicht geht.

Dabei sollen nur ganze Dateien kopiert werden. Haben mehrere Dateien denselben Pfad relativ zu den Wurzeln der zusammenzuführenden Verzeichnisse, aus denen sie stammen, so ist dies als Konflikt zu betrachten, und keine Dateien sollen kopiert werden. Insbesondere soll das Programm also weder Inhalte überschreiben, noch innerhalb einer Ziel-Datei konkatenieren, noch zeilenbasiert oder anderweitig innerhalb einer Datei zu "mergen" versuchen.

Ausgabe im Konfliktfall

Für jeden relativen Pfad, für den ein Konflikt festgestellt wurde soll ausgegeben werden:

• dieser relative Pfad
• in welchen der zusammenzuführenden Verzeichnisse er vorkommt

Use-Case und Motivation

Ich (@das-g) habe die Verantwortung für eine Vereinswebsite übernommen. Diese wurde mit einer proprietären Software erstellt, die mir als Linux-Benutzer nicht zur Verfügung steht. Die Website ist serverseitig statisch und liegt mir als zu hostendes Verzeichnis mit HTML-, CSS- und Bild-Dateien vor.

Um die Website und ihre Inhalte pflegen zu können, ohne händisch in maschinen-generiertem HTML rumfummeln zu müssen, würde ich sie gerne mit einem (natürlich FLOSS-lizenzierten) Static-Site-Generator (z.B. Hugo) neu machen. Es ist mir jedoch zu viel, in meiner Freizeit die ganze Website mit all ihren Unterseiten aufs Mal damit neu zu machen. Ich würde lieber Schritt für Schritt vorgehen, Inhalte nach und nach (Unterseite für Unterseite) in die neue Struktur übernehmen. Dabei will ich durchgängig sowohl umgestellte als auch noch nicht umgestellte Inhalte online haben.

Meine Idee ist somit folgende Struktur mit folgendem Vorgehen:

Struktur:

Repo mit 2 Toplevel-Verzeichnissen:

1. Legacy-Website (anfangs wie vom Vorgänger übernommen)
2. Quell-Dokumente für den Static-Site-Generator (anfangs leer)

Vorgehen:

Wiederhole bis fertig:

1. eine Unterseite dem Legacy-Website-Verzeichnis aussuchen
2. deren Inhalte in die Quell-Dokumente für den Static-Site-Generator einpflegen
3. die Unterseite aus der Legacy-Website-Verzeichnis löschen
4. falls notwendig, damit die alte URL der Unterseite gültig bleibt, in der Config für den Static-Site-Generator eine Weiterleitung anlegen
5. Static-Site-Generator ausführen
6. Legacy-Website-Verzeichnis und Ausgabe-Verzeichnis des Static-Site-Generators zusammenführen
7. Ergebnis der Zusammenführung als neuen (Zwischen-)Stand der Vereinswebsite hosten

Für Schritt 6 bräuchte ich das hier zu erstellende Tool.

Schritte 5 bis 7 würden in der CI/CD-Pipeline automatisiert. Deswegen soll das Tool ein nicht-interaktives CLI-Tool sein.

Das Prüfen der Konflikt-Freiheit soll sicherstellen,

• dass das Löschen der Unterseite aus der Legacy-Website-Verzeichnis (Schritt 4) nicht vergessen ging
• dass keine anderen unerwarteten Pfad-Kollisionen entstanden sind

Überlegungen

• Für obigen Use-Case genügt das Zusammenführen von zwei Verzeichnissen. Ich denke aber, das Tool wäre cooler (und besser für weitere Use-Cases brauchbar), wenn es auch mehr Verzeichnisse so zusammenführen kann.
• Bei nicht-atomaren Dateisystem-Operationen muss man normalerweise Nebenläufigkeit mit anderen Prozessen beachten. Für meinen obigen Use-Case (und wohl generell für derartige Verwendung in CI/CD) ist das jedoch nicht notwendig, da einigermassen garantiert ist, dass nur der (sequenzielle) CI/CD-Script die fraglichen Verzeichnisse manipuliert. Das Tool (mit Locking oder mit exklusiven File-Handles oder so) Multiprocessing-save zu machen, wäre aber eine interessante Ausbau-Möglichkeit.
• Wie muss das Programm mit speziellen Dateien (Symlinks, Device Files, Process Files, ...) umgehen, damit obige Spezifikation erfüllt wird?

Mögliche (optionale) Ausbau-Möglichkeiten

• Multiprocessing-safety (siehe Überlegungen oben)
• Dateien mit gleichem relativen Pfad nicht als Konflikt betrachten, wenn sie byte-exakt denselben Datei-Inhalt haben
• Option(en) zur Steuerung, wie Symlinks (bei Konfliktfreiheitsprüfung und beim Zusammenführen) behandelt werden sollen

Mob-Programming in Haskell

Warum Mob-Programming?

• Weil ich das gerne mal ausprobieren will.
• Weil ich nicht sicher bin, ob ich dieses Programm allein in sinnvoller Zeit umsetzen könnte.

Warum Haskell?

• Weil ich gerne Erfahrung sammeln will, Haskell auf etwas anzuwenden, das über die Übungsaufgaben im OST-BSc-Modul FP hinaus geht:
  • Umgang mit Dateisystem
  • Nicht-triviale (aber trotzdem überschaubare) Problemstellung
• Weil ich glaube, dass die Problemstellung für Haskell eigentlich gut geeignet sein müsste.

Muss man schon Haskell können, um mitzumachen?

Nein. Beim Mob-Programming können wir voneinander lernen und auch ohne einschlägige Vorkenntnisse kann man mitmachen, sofern man den Computer grundlegend bedienen kann.

🎬 Formate

🛠 Workshop

🎤 Präsentiert von

@das-g

⏱️ Dauer

Vermutlich 2 bis 3 Sessions à je 2 bis 3 h

📌 Status

Vorschlag