Frappe und ERPNext Germany: Tenacity-Versionen im Konflikt?

Der belegte Versionskonflikt

Der Originalbericht nennt Frappe 16.52.0 und einen konkreten ERPNext-Germany-Stand. Q1 Im veröffentlichten Frappe-Code steht tenacity~=9.1.2; der referenzierte Germany-Commit verlangt tenacity~=8.2.3. Q2 Q3 Nach den Regeln kompatibler Python-Versionsbereiche überschneiden sich diese beiden Anforderungen nicht. Q5 Das ist für diese Stände ein nachprüfbarer Konflikt, keine Behauptung über alle späteren Releases.

Eine lokal geänderte Anforderung kann den Installer zufriedenstellen, beweist aber noch nicht, dass die betroffenen Anwendungen mit der neuen Bibliothek korrekt funktionieren.

Den tatsächlichen Paketstand erfassen

1. Umgebung eindeutig bestimmen. Notiere Python-Version, Frappe-, ERPNext- und Germany-Version samt Git-Revision. Achte darauf, die virtuelle Umgebung des betroffenen Bench zu prüfen und nicht ein global installiertes Python.
2. Abhängigkeiten lesen. Vergleiche die tatsächlich installierten Projektdateien mit den referenzierten Releases. Ein Branchname wie „version-16“ ist weniger präzise als der konkrete Commit, der auf deinem Server liegt.
3. Konsistenz prüfen. Führe im richtigen Python-Kontext python -m pip check aus und sichere die Ausgabe. pip beschreibt dies als Prüfung kompatibler installierter Abhängigkeiten. Q4 Der Befehl ist ein Nachweis der Paketkonsistenz, kein vollständiger Anwendungstest.
4. Unterstützte Kombination suchen. Prüfe, ob ein Maintainer-Release den Konflikt bereits auflöst und welche Frappe-/ERPNext-Stände dazu passen. Baue diese Kombination zuerst in einer getrennten Umgebung mit nachvollziehbaren Versionen auf.
5. Betroffene Funktionen testen. Wenn ein abgestimmter Patch nötig ist, teste die konkret von Tenacity abhängigen Pfade einschließlich Wiederholung und Fehlerbehandlung. Simuliere externe Antworten in Tests; ein erfolgreicher Import des Python-Moduls genügt nicht.

Eine belastbare Lösung dokumentieren

Halte die kompatible Kombination und den Grund für jede Abweichung fest. --no-deps, abwechselnde Zwangsinstallationen oder unkommentierte Änderungen unter installierten Paketen machen den Konflikt nicht fachlich gelöst. Ein späterer regulärer Build sollte denselben gültigen Zustand reproduzieren können.

Häufige Fragen

Kann ich einfach die höhere Version nehmen?

Nur wenn die beteiligten Anwendungen diese Kombination unterstützen beziehungsweise sie gezielt qualifiziert wurde. Eine höhere Nummer allein ist kein Kompatibilitätsnachweis.

Was braucht eine Unterstützung?

Versionen mit Commits, Python-Interpreterpfad, die relevanten Abhängigkeitszeilen und pip check-Ausgabe. Kundendaten oder produktive Zugangsdaten werden für die Diagnose dieses Paketkonflikts nicht benötigt.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0541 mit KAN KAI WORKS besprechen.