Fabric: 'abort_on_prompts' remplace warn_only = True

(Protip, utilisez le lien "Github Flavored Markdown" au-dessus des champs de texte, il vous montrera comment formater les choses correctement. Correction de votre description pour vous :))

Je dirais que dans la plupart des cas, lorsque les utilisateurs basculent abort_on_prompts , ils s'attendent _probablement_ au comportement actuel (abandonner) et non à un avertissement et à continuer. warn_only=True s'applique généralement à ce qu'il faut faire lorsque _le programme distant_ a un échec, vs Fabric lui-même abandonne.

Cependant, je reconnais que cette situation où les deux sont vrais, n'est pas bien définie / documentée. De plus, la plupart des autres utilisations de abort() dans la base de code ont été remplacées par des appels à error() qui gère la logique "abandonner si warn_only=False ".

Je vais appeler pour l'instant que la cohérence l'emporte sur la possibilité pour un utilisateur d'essayer d'annuler les invites et d'être contrecarré par un warn_only=True inattendu, et effectuera le changement que vous demandez. Si d'autres personnes viennent se plaindre, je vous mettrai en avant;)

À la réflexion, je suis vraiment déchiré à ce sujet; Je peux voir le changement gâcher les choses pour les utilisateurs qui, comme mentionné, veulent vraiment que Fabric explose à des invites inattendues. Les erreurs cachées peuvent être incroyablement frustrantes à localiser.

@pkittenis - dans quelle situation réelle rencontrez-vous où c'est un problème pour vous? Pourriez-vous utiliser try/except SystemExit pour contourner ce problème?

Si vous êtes bloqué par cela, ce qui pourrait avoir plus de sens est d'ajouter une nouvelle option de configuration (avec un nom stupide comme warn_trumps_abort peut-être) afin que les personnes dans votre cas d'utilisation puissent contrôler le comportement, sans provoquer de changement inattendu pour les utilisateurs actuels.

Le problème est que le comportement de abort_on_prompts oblige le fabric à lancer un SystemExit lorsqu'il revient à No hosts found. Please specify (single) host string for connection: lorsqu'une commande a une erreur.

Lorsque vous utilisez Fabric comme API, c'est tout simplement faux IMO. L'utilisateur de l'API a déjà défini warn_only pour éviter une sortie système lors de l'exécution et à la place être en mesure de gérer les codes de retour dans le code. C'est super.

Ensuite, l'utilisateur définit abort_on_prompts et au lieu d'obtenir le code d'erreur de sa commande en cas d'échec, il obtient un SystemExit en raison du retour à enter a host et de l'utilisation de abort_on_prompts . Peut gérer l'exception, bien sûr, mais dans ce cas, vous ne pouvez plus voir le code de retour de la commande qui a échoué.

Peut contourner pour l'instant en réinitialisant abort_on_prompts à False, mais cela doit être fait sur chaque commande qui peut échouer ou non,

Je suppose que ce qui serait le mieux serait un drapeau pour désactiver complètement les invites de fabric intégrées destinées à être utilisées sur la ligne de commande, en particulier le No hosts found.. one, lors de l'utilisation de fabric comme API. Alors abort_on_prompts ne provoquerait pas de sortie système car il n'y a pas d'invite pour le provoquer.

+1 - Je rencontre ce problème en ce moment même. Mon cas d'utilisation concret est que j'utilise Fabric afin de vérifier les nœuds cloud récemment provisionnés et de confirmer si ces nœuds ont un accès SSH avec la clé publique appropriée. En conséquence, je dois réellement _catch_ l'exception abort_on_prompts. Pour l'instant, je vais juste attraper explicitement SystemExit, mais cela semble vraiment faux.

+1 - Je voudrais également attraper les exceptions abort_on_prompts.

: +1: Je suis dans la même situation où je ne veux pas que SystemExit soit élevé - cela tue mes céleris.

À ce stade, je pense que ce niveau de changement correspond mieux à la version 2.0, qui est d'abord conçue avec le cas d'utilisation de l'API et le cas d'utilisation de la CLI comme cas d'utilisation secondaire / wrapper. Changer le comportement dans 1.x sera trop surprenant / déroutant / susceptible d'ajouter des bogues.

Marquer comme 2.x et laisser ouvert afin que je puisse, espérons-le, revoir et m'assurer de le prendre en compte lors de l'écriture de cette partie de l'API.

+1 - lorsque abort_on_prompts et warn_only sont tous les deux _Vrai_, warn_only devrait prévaloir.
Un autre fil sur ce problème, par @reeesga : https://github.com/fabric/fabric/issues/521

+1

+1 - lorsque abort_on_prompts et warn_only sont tous les deux Vrai, warn_only devrait prévaloir. Un paramètre plus récent pour ce faire convient également

Une mise à jour pour ceci ?
J'ai attrapé SystemExit mais cela rend juste ma sortie moche ...

Voyez par vous-même:

webapps2adm001.qa.aws.company.com: connexion en tant que root SUCCESS.
webapps2001.qa.aws.company.com: Connexion en tant que root SUCCESS.

Erreur fatale: nécessaire pour demander un mot de passe de connexion ou sudo (hôte: webapps3001.ia.aws.company.com), mais l'entrée serait ambiguë en mode parallèle

Abandon.
webapps3001.ia.aws.company.com: Échec de la connexion en tant que root. Sortie système: 1
webapps3adm001.ia.aws.company.com: connexion en tant que root SUCCESS.

Je veux juste garder la ligne après un abandon. Je ne veux pas voir les messages d'erreur.

Je rencontre également ce problème et j'aimerais voir le comportement actuel changé.