2 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Opus 5	bfc0cada62	fix(windows): kein CMD-Fenster mehr — die EXE ist ein Fenster-Programm ... Commander: "Unterbinde das CMD Fenster was sich beim oeffnen mitoeffnet." Mein erster Anlauf wollte die Konsole VERSTECKEN und war falsch, aus zwei Gruenden: * Eine Onefile-EXE ist ZWEI Prozesse (gemessen: PID 33172 mit 8 MB, PID 33580 mit 103 MB, beide Rippy.exe). Die Pruefung "haengt genau EIN Prozess an der Konsole" war damit nie wahr, das Fenster blieb einfach stehen. * Selbst wenn sie ginge, waere das Fenster erst nach ein bis zwei Sekunden weg. Ein Aufblitzen ist kein "unterbunden". Jetzt wird die Konsole gar nicht erst erzeugt: --windowed statt --console. Nachgemessen am fertigen Bau -- PE-Subsystem 2 (GUI) statt 3 (Konsole), und beim Klick auf die Desktop-Verknuepfung ist genau EIN sichtbares Fenster da: die WinForms-Oberflaeche. Kein ConsoleWindowClass-Fenster von Rippy, weder sichtbar noch unsichtbar. Was dazugehoert, damit daraus kein stiller Fehlschlag wird: * Ohne Konsole ist sys.stdout None. uvicorn schreibt auf stderr und waere mitten im Start gestorben, ohne dass irgendwo etwas stuende. einstieg.py haengt sich deshalb an die Konsole des Aufrufers (--status in PowerShell schreibt weiter dorthin) oder leitet nach %LOCALAPPDATA%\Rippy\rippy.log um. * Der Installer meldet sein Ergebnis in einem Fenster, wenn keine Konsole da ist -- sonst saehe ein gescheiterter Doppelklick aus wie einer, der nichts tut. Bei --still und mit Konsole bleibt es bei der Textzeile. Gegengeprueft am laufenden Programm: /api/health, / und /api/capabilities antworten mit 200, und rippy.log faengt auf, was vorher ins Leere ging. fix(drives): linux.py reicht die detection-Funktionen wieder durch Die Ampel war seit Lauf 181 rot -- vier Commits lang, und ich hatte es uebersehen. Ursache: docker/api/main.py:54 AttributeError: module 'rippy.drives.linux' has no attribute 'drive_status' main.py holt sich beim Import device_discovery.drive_status. Der Windows-Treiber hat die Funktion; linux.py hatte sie nicht mehr, seit detection (und damit fcntl) bewusst nicht mehr oben importiert wird -- sonst waere main.py unter Windows nicht ladbar. Unter Windows lief also alles, auf Linux waere der API-Container gar nicht hochgekommen. Behoben mit PEP 562 (__getattr__), demselben Kniff wie in store/__init__.py: Der Import bleibt ohne fcntl moeglich, wer die Funktionen BENUTZT bekommt sie. Dazu drei weitere Fehler, die nur auf Linux auftraten: * katalog.py baute Windows-Pfade mit os.path.join. Auf dem Linux-Runner wurde daraus C:\Program Files (x86)\MakeMKV/makemkvcon64.exe. Jetzt entscheidet der Pfad selbst ueber den Trenner, nicht die rechnende Maschine. * verknuepfungen.py nahm os.path.dirname fuer den Arbeitsordner einer .lnk. Eine .lnk zeigt IMMER auf einen Windows-Pfad -- also ntpath. * waechter.py las 0.0 als Zeitpunkt statt als "noch nie geprueft". Auf einer frisch gestarteten Maschine ist time.monotonic() klein, also fiel die erste Laufwerks-Abfrage aus. None statt 0.0. Alle vier haben jetzt Tests, die auf JEDER Plattform laufen -- der Treiber-Test schiebt eine detection-Attrappe unter, der Waechter-Test stellt eine Uhr bei 0,5 s nach, die Pfad-Tests pruefen beide Zweige. Beim Wegnehmen der Durchreiche rot gesehen (5 Fehlschlaege), danach wieder gruen. Damit faengt die Ampel so etwas kuenftig, ohne dass es eine Linux-Umgebung auf dem Entwicklungsrechner braucht. Ampel lokal: 582 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:41:10 +02:00
HitonabiandClaude Opus 5	059183c651	feat(windows): V2-4 fertig — RippySetup.exe, Taskmanager-Eintrag, Deinstallation ... WAS: Eine 28,6-MB-Datei, drei Betriebsarten. Doppelklick installiert, `--dienst` laeuft im Hintergrund, `--deinstallieren` raeumt sich weg. Dazu packaging/windows/build.py, das sie baut. DIE ZWEI COMMANDER-WUENSCHE, GEMESSEN: 1. EINTRAG IM TASKMANAGER ProcessName Rippy Beschreibung Rippy — automatisches Ripping Produkt Rippy Version 2.0.0 Der Prozessname kommt vom Dateinamen (bei der Installation kopiert sich die Datei als Rippy.exe), die Beschreibung aus einer eingebetteten Versions-Ressource. Ohne die steht dort nichts, und Windows SmartScreen sieht eine EXE ohne Herausgeberangabe genauso misstrauisch wie ein Mensch. 2. EINTRAG IN PROGRAMME UND FEATURES Aus der Registry zurueckgelesen, nicht behauptet: DisplayName Rippy DisplayVersion 2.0.0 Publisher Rippy InstallLocation <Zielordner> UninstallString "<pfad>\Rippy.exe" --deinstallieren EstimatedSize 29241 (KiB) NoModify/NoRepair 1 HKCU statt HKLM: Der Eintrag erscheint genauso in "Apps & Features", die Installation laeuft aber ohne UAC-Abfrage durch. VOLLER KREISLAUF GEMESSEN: installieren -> Rippy.exe + rippy.ico liegen da, Registry-Eintrag da, Autostart da; Dienst starten -> nach 1 s bereit, alle sieben Endpunkte HTTP 200, Oberflaeche kommt; deinstallieren -> nach ~4 s sind Datei, Ordner, Registry-Eintrag, Autostart UND das Aufraeum-Skript weg. VIER FEHLER, DIE NUR DIE FERTIGE EXE ZEIGT: 1. rippy/store baute die Engine BEIM IMPORT, mit PostgreSQL als Vorgabe. Im Windows-Paket gibt es psycopg2 bewusst nicht -> die EXE starb sofort. Die Engine entsteht jetzt beim ersten Zugriff. Und der Fehler war grundsaetzlicher als der fehlende Treiber: Ein Modul, das beim Import schon eine Verbindung aufbaut, laesst sich gar nicht mehr umstellen — store.verbinden() kaeme immer zu spaet. 2. celery_client baute den Broker-Client beim Import. Dasselbe Muster, und `from celery_client import celery_client` loeste es sogar dann aus, wenn nie ein Rip angestossen wird. Jetzt traege, mit KeinBroker als klarer Ansage statt eines Importfehlers. 3. Die Selbstloeschung beim Deinstallieren ging als EIN Argument an cmd. Python maskiert dabei die inneren Anfuehrungszeichen — cmd suchte einen Dateinamen mit Backslashes davor, fand nichts und meldete nichts (>nul). Registry und Autostart waren weg, die 28-MB-Datei blieb liegen: ein still scheiternder Hintergrundprozess, wie ihn AGENTS.md beschreibt. Jetzt ein Aufraeum-Skript, das 15-mal versucht (die Onefile-EXE laeuft als ZWEI Prozesse; der Starter haelt die Datei nach dem Ende noch offen). 4. deinstallieren() raeumte den STANDARD-Ordner auf statt des tatsaechlichen. Wer nach --ziel D:\Rippy installiert hatte, dessen Dateien waeren geblieben, waehrend ein fremder Ordner angefasst worden waere. Der Pfad steht in der Registry (InstallLocation) und wird jetzt dort gelesen. WAS NOCH NICHT GEHT, ausdruecklich: Ein RIP laesst sich unter Windows noch nicht anstossen — die Zustellung laeuft weiter ueber Celery. Die Umstellung auf die LocalQueue ist V2-5. Oberflaeche, Laufwerks-Erkennung, Auswurf und alles Lesende laufen. GEMESSEN: ruff sauber, 456 Tests gruen + 15 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:00:39 +02:00