Fabric: 'abort_on_prompts' überschreibt warn_only = True

(Protip, benutze den Link "Github Flavored Markdown" über den Textfeldern, er zeigt dir, wie man Dinge richtig formatiert. Deine Beschreibung für dich korrigiert :))

Ich würde argumentieren, dass Benutzer in den meisten Fällen, wenn sie abort_on_prompts umschalten, wahrscheinlich das aktuelle Verhalten (Abbruch) erwarten und kein Warnen und Fortfahren. warn_only=True gilt normalerweise für das, was zu tun ist, wenn das Remote-Programm einen Fehler aufweist, während Fabric selbst abbricht.

Ich erkenne jedoch an, dass diese Situation, in der beide wahr sind, nicht gut definiert / dokumentiert ist. Darüber hinaus wurden die meisten anderen Verwendungen von abort() in der Codebasis durch Aufrufe von error() , was die Logik "Abbruch wenn warn_only=False " behandelt.

Ich rufe vorerst an, dass die Konsistenz die Möglichkeit übertrifft, dass ein Benutzer versucht, bei Eingabeaufforderungen abzubrechen, und von einem unerwarteten warn_only=True vereitelt wird, und die von Ihnen angeforderte Änderung vornimmt. Wenn andere Leute sich beschweren, werde ich dich trotzdem nach vorne bringen;)

Nachdenklich bin ich wirklich hin und her gerissen; Ich kann sehen, wie die Änderung die Dinge für Benutzer vermasselt, die, wie erwähnt, wirklich wollen, dass Fabric bei unerwarteten Eingabeaufforderungen in die Luft sprengt. Versteckte Fehler können unglaublich frustrierend sein.

@pkittenis - in welche reale Situation geraten Sie, wo dies ein Problem für Sie ist? Könnten Sie try/except SystemExit , um das Problem zu umgehen?

Wenn Sie dadurch schwer blockiert werden, ist es möglicherweise sinnvoller, eine neue Konfigurationsoption hinzuzufügen (mit einem dummen Namen wie warn_trumps_abort vielleicht), damit die Benutzer in Ihrem Anwendungsfall das Verhalten steuern können, ohne eine unerwartete Änderung zu verursachen für aktuelle Benutzer.

Das Problem ist, dass das Verhalten von abort_on_prompts dass Fabric einen SystemExit auslöst, wenn es auf No hosts found. Please specify (single) host string for connection: zurückfällt, wenn ein Befehl einen Fehler aufweist.

Wenn Sie Fabric als API verwenden, ist das IMO einfach falsch. Der Benutzer der API hat bereits warn_only , um einen SystemExit bei der Ausführung zu vermeiden und stattdessen Rückkehrcodes innerhalb des Codes verarbeiten zu können. Das ist großartig.

Dann setzt der Benutzer abort_on_prompts und anstatt den Fehlercode für seinen Befehl zu erhalten, wenn dieser fehlschlägt, erhält er einen SystemExit aufgrund des Fallbacks auf enter a host und der Verwendung von abort_on_prompts . Kann die Ausnahme zwar behandeln, aber in diesem Fall können Sie den Rückkehrcode des fehlgeschlagenen Befehls nicht mehr sehen.

Kann vorerst umgangen werden, indem abort_on_prompts auf False zurückgesetzt wird. Dies muss jedoch für jeden Befehl ausgeführt werden, der möglicherweise fehlschlägt oder nicht.

Ich nehme an, was am besten wäre, wäre ein Flag, um eingebaute Fabric-Eingabeaufforderungen, die in der Befehlszeile verwendet werden sollen, insbesondere die No hosts found.. 1, vollständig zu deaktivieren, wenn Fabric als API verwendet wird. Dann würde abort_on_prompts keinen SystemExit verursachen, da es keine Aufforderung gibt, dies zu verursachen.

+1 - Ich stoße gerade auf dieses Problem. Mein konkreter Anwendungsfall ist, dass ich Fabric verwende, um kürzlich bereitgestellte Cloud-Knoten zu überprüfen und zu bestätigen, ob diese Knoten SSH-Zugriff mit dem entsprechenden öffentlichen Schlüssel haben. Infolgedessen muss ich die Ausnahme abort_on_prompts tatsächlich abfangen. Im Moment werde ich SystemExit nur explizit abfangen, aber das fühlt sich in der Tat sehr falsch an.

+1 - Ich möchte auch abort_on_prompts Ausnahmen abfangen.

: +1: Ich bin in der gleichen Situation, in der ich nicht möchte, dass SystemExit erhöht wird - das tötet meine Sellerie-Arbeiter.

Zum jetzigen Zeitpunkt passt diese Änderungsstufe meiner Meinung nach besser in Version 2.0, die mit dem API-Anwendungsfall zuerst und dem CLI-Anwendungsfall als sekundärem / Wrapper-Anwendungsfall entwickelt wird. Das Ändern des Verhaltens in 1.x ist zu überraschend / verwirrend / kann zu Fehlern führen.

Als 2.x markieren und offen lassen, damit ich es hoffentlich erneut besuchen und sicherstellen kann, dass ich es beim Schreiben dieses Teils der API berücksichtige.

+1 - Wenn sowohl abort_on_prompts als auch warn_only _True_ sind, sollte warn_only Vorrang haben.
Ein weiterer Thread zu diesem Thema von @reeesga : https://github.com/fabric/fabric/issues/521

+1

+1 - Wenn sowohl abort_on_prompts als auch warn_only True sind, sollte warn_only Vorrang haben. Eine neuere Einstellung hierfür ist ebenfalls in Ordnung

Gibt es hierzu Neuigkeiten ?
Ich habe SystemExit abgefangen, aber es macht meine Ausgabe nur hässlich ...

Überzeugen Sie sich selbst:

webapps2adm001.qa.aws.company.com: Verbindung als Root-ERFOLG.
webapps2001.qa.aws.company.com: Verbindung als Root-ERFOLG.

Schwerwiegender Fehler: Erforderlich, um eine Verbindung oder ein Sudo-Passwort einzugeben (Host: webapps3001.ia.aws.company.com), aber die Eingabe wäre im parallelen Modus nicht eindeutig

Abbruch.
webapps3001.ia.aws.company.com: Verbindung als Root fehlgeschlagen. SystemExit: 1
webapps3adm001.ia.aws.company.com: Verbindung als Root-ERFOLG.

Ich möchte nur nach dem Abbruch die Leitung behalten. Ich möchte die Fehlermeldungen nicht sehen.

Ich stoße auch auf dieses Problem und würde gerne sehen, wie sich das aktuelle Verhalten ändert.