HitonabiandClaude Opus 5
b98dc5eef5
Ampel / ampel (push) Successful in 41s
WAS: Neues Paket src/rippy (core/drives/rip). detection.py,
makemkv_daten.py und notify.py lagen je ZWEIMAL im Repo — unter
docker/api UND docker/worker, byte-identisch. Jetzt gibt es sie einmal;
beide Container importieren dieselbe Datei. Verhalten unveraendert.
WARUM: Es gab kein geteiltes Paket zwischen den Containern, deshalb die
Kopien. docker/api/db.py sagt es im Kopfkommentar selbst: "Wer die
Struktur aendert, aendert BEIDE Dateien." Ein Waechter-Test
(test_zwillinge_sind_byteweise_identisch) hat das mechanisch
abgesichert — er war noetig, weil die Konstruktion falsch war. Erste
Etappe des v2-Plans (KONZEPT-V2.md §8.3).
IM EINZELNEN:
- src/rippy/{core/notify, drives/detection, rip/makemkv_daten}.py
- conftest.py in der Wurzel legt src/ auf den sys.path (die Ampel ruft
pytest dort auf).
- Beide Dockerfiles kopieren src/rippy nach /app/rippy — /app ist
Arbeitsverzeichnis und uvicorn-App-Dir, also ohne PYTHONPATH findbar.
- worker_setup_paket packt das Paket ausdruecklich mit ins Zip: die
Schleife sah nur die oberste Ebene, ein Unterordner waere nie
mitgekommen und der Windows-Worker beim Start gestorben.
- Die zwei Test-Dateien fuer makemkv_daten sind zu einer verschmolzen
(die Faelle aus beiden). Damit entfaellt auch der importlib-Umweg im
Worker-Test: der war noetig, weil bei "pytest -q" aus der Wurzel
docker/api zuerst eingesammelt wird und jeder weitere Import nur noch
den sys.modules-Cache trifft — die Worker-Kopie wurde also nie
angefasst. Netto -13 doppelte Tests, +2 neue (siehe unten).
EIN FEHLER, DEN DER UMBAU FAST AUSGELIEFERT HAETTE: In tasks.py steht
der detection-Import in einem "try/except ImportError" — absichtlich,
denn der native Windows-Worker hat kein fcntl und soll trotzdem
starten. Das except verschluckt aber JEDEN ImportError, auch einen
falschen Modulpfad. Auf Linux haette der Worker ab sofort still
detect_disc_type=None gesetzt und jeden Rip verweigert, ohne dass
irgendwo ein Fehler stuende — genau die Klasse "still scheiternder
Hintergrund-Prozess" aus AGENTS.md. Gefunden ueber eine zweite Suche
mit eingerueckten Treffern.
Waechter dagegen: src/rippy/test_paket.py prueft mit
importlib.util.find_spec (fuehrt nichts aus, laeuft also auch auf
Windows ohne fcntl), dass es die drei Modulpfade wirklich gibt. Beim
Wegnehmen von detection.py gegengeprueft: Test wird rot, nach
Wiederherstellen gruen.
GEMESSEN: ruff sauber, 290 Tests gruen + 1 uebersprungen (lokal, ohne
die zwei Linux-only-Module). Kein Modul liegt noch doppelt im Repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
2.0 KiB
Docker
45 lines
2.0 KiB
Docker
FROM python:3.12-slim-bookworm
|
|
|
|
WORKDIR /app
|
|
|
|
# udev ist raus (23.07.): udevadm lieferte im Container nie Daten (kein udevd) —
|
|
# die Geräte-Erkennung läuft jetzt über /sys + ioctls.
|
|
# nfs-common/cifs-utils: Netzwerk-Speicherziele werden aus dem UI heraus
|
|
# eingehängt (mounts.py, braucht CAP_SYS_ADMIN aus dem Compose).
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
nfs-common \
|
|
cifs-utils \
|
|
smbclient \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
COPY docker/api/requirements.txt .
|
|
RUN pip install --no-cache-dir -r requirements.txt
|
|
|
|
COPY docker/api/ .
|
|
|
|
# Gemeinsamer Kern (Etappe V2-0): liegt im Repo unter src/rippy, im Image
|
|
# neben den API-Modulen. /app ist Arbeitsverzeichnis und uvicorn-App-Dir,
|
|
# damit findet "import rippy" das Paket ohne PYTHONPATH.
|
|
COPY src/rippy ./rippy
|
|
|
|
# Worker-Selbstversorgung: die API liefert Installer + Worker-Code an
|
|
# native Worker aus (GET /worker-setup/windows bzw. /worker-setup/paket) —
|
|
# die Zielmaschine braucht weder git noch Docker.
|
|
COPY docker/worker/*.py docker/worker/requirements.txt worker_dist/
|
|
# Der Worker importiert seit V2-0 aus dem gemeinsamen Paket (tasks.py, caps.py).
|
|
# Ohne diese Zeile fehlte es im Zip und der Windows-Worker stürbe beim Start
|
|
# mit ModuleNotFoundError — worker_setup_paket packt genau diesen Ordner mit ein.
|
|
COPY src/rippy worker_dist/rippy
|
|
COPY deploy/worker-windows/installer.py worker_dist/
|
|
# Rippy-Icon: Der Installer legt damit eine Verknüpfung auf den Desktop
|
|
# (Commander-Wunsch 26.07.2026). Ohne die Datei auf der Zielmaschine trüge die
|
|
# Verknüpfung das Standard-Batch-Symbol — und niemand fände sie zwischen den
|
|
# anderen Icons wieder.
|
|
COPY deploy/worker-windows/rippy.ico worker_dist/
|
|
# Vorgebaute .exe (Rippy-Icon, kein Konsolenfenster) — auf Windows via
|
|
# deploy/worker-windows/build-exe.ps1 erzeugt (Windows-.exe geht nicht von
|
|
# Linux). Nur bei GUI-Aenderungen neu bauen, nicht bei Tool-Updates.
|
|
COPY deploy/worker-windows/RippyWorkerSetup.exe worker_dist/
|
|
|
|
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--app-dir", "/app"]
|