Fabric: تجاوزات 'abort_on_prompts' warn_only = صحيح

تم إنشاؤها على ٢٢ أكتوبر ٢٠١٢ · 12تعليقات · مصدر: fabric/fabric

محاولة استخدام كل من abort_on_prompts و warn_only = True يجعل abort_on_prompts يتجاوز warn_only ولا يزال النسيج يطرح SystemExit

In [6]: from fabric.api import sudo, execute, cd, env, run, local

In [7]: with settings(warn_only = True):
    result = local("ls -ltrh")
   ...:     
[localhost] local: ls -ltrh
total 188K
In [8]: with settings(warn_only = True):
    result = local("ls -ltrh /tmp/tartratrat")
   ...:     
[localhost] local: ls -ltrh /tmp/tartratrat
ls: cannot access /tmp/tartratrat: No such file or directory

Warning: local() encountered an error (return code 2) while executing 'ls -ltrh /tmp/tartratrat'


In [9]: env['abort_on_prompts'] = True

In [10]: with settings(warn_only = True):
    result = local("ls -ltrh /tmp/tartratrat")
   ....:     
[localhost] local: ls -ltrh /tmp/tartratrat
ls: cannot access /tmp/tartratrat: No such file or directory

Warning: local() encountered an error (return code 2) while executing 'ls -ltrh /tmp/tartratrat'


In [11]: with settings(warn_only = True):
    result = run("ls -ltrh /tmp/tartratrat")
   ....:     

Fatal error: Needed to prompt for the target host connection string, but abort-on-prompts was set to True

Aborting.
An exception has occurred, use %tb to see the full traceback.

SystemExit: 1
To exit: use 'exit', 'quit', or Ctrl-D.

Bug Core

مصدر

pkittenis

👍1

ال 12 كومينتر

(Protip ، استخدم رابط "Github Flavored Markdown" أعلى الحقول النصية ، وسوف يوضح لك كيفية تنسيق الأشياء بشكل صحيح. أصلح الوصف الخاص بك :))

أود أن أزعم أنه في معظم الحالات عندما يقوم المستخدمون بتبديل abort_on_prompts ، فإنهم _ من المحتمل _ يتوقعون السلوك الحالي (إحباط) وليس تحذيرًا ومتابعة. ينطبق warn_only=True عادةً على ما يجب فعله عند فشل البرنامج البعيد ، في مقابل إحباط Fabric نفسه.

ومع ذلك ، أقر بأن هذا الموقف حيث كلاهما صحيح ، لم يتم تعريفه / توثيقه جيدًا. بالإضافة إلى ذلك ، تم استبدال معظم الاستخدامات الأخرى لـ abort() في قاعدة الشفرة باستدعاءات إلى error() وهو ما يتعامل مع منطق "abort if warn_only=False ".

سأتصل الآن بأن التناسق يتفوق على احتمال أن يحاول المستخدم الإجهاض عند المطالبات ويتم إحباطه من خلال warn_only=True غير متوقع ، وسوف يقوم بإجراء التغيير الذي تطلبه. إذا جاء أشخاص آخرون يشتكون ، فسوف أضعك في المقدمة رغم ذلك ؛)

bitprophet في ٢٩ أكتوبر ٢٠١٢

عند التفكير ، أنا ممزق حقًا بشأن هذا ؛ أستطيع أن أرى التغيير الذي يفسد الأشياء للمستخدمين الذين ، كما ذكرنا ، يريدون حقًا أن ينفجر النسيج في مطالبات غير متوقعة. يمكن أن تكون الأخطاء المخفية محبطة للغاية لتعقبها.

pkittenis - ما هو الوضع الواقعي الذي try/except SystemExit لحل المشكلة؟

إذا كنت محظورًا بشدة بسبب هذا ، فإن ما قد يكون أكثر منطقية هو إضافة بعض خيارات التكوين الجديدة (مع بعض الأسماء الغبية مثل warn_trumps_abort ربما) حتى يتمكن الأشخاص في حالة الاستخدام الخاصة بك من التحكم في السلوك ، دون التسبب في تغيير غير متوقع للمستخدمين الحاليين.

bitprophet في ٢٩ أكتوبر ٢٠١٢

تكمن المشكلة في أن سلوك abort_on_prompts يتسبب في قيام النسيج برمي SystemExit عندما يعود إلى No hosts found. Please specify (single) host string for connection: عندما يكون هناك خطأ في الأمر.

عند استخدام النسيج كواجهة برمجة تطبيقات ، فهذا خطأ IMO. لقد قام مستخدم API بالفعل بتعيين warn_only لتجنب SystemExit عند التنفيذ ، وبدلاً من ذلك يكون قادرًا على التعامل مع رموز الإرجاع داخل التعليمات البرمجية. هذا جيد.

ثم يقوم المستخدم بتعيين abort_on_prompts وبدلاً من الحصول على رمز الخطأ لأمره عندما يفشل ، يحصل على SystemExit بسبب الرجوع إلى enter a host واستخدام abort_on_prompts . يمكنك التعامل مع الاستثناء ، بالتأكيد ، ولكن في هذه الحالة لا يمكنك رؤية رمز الإرجاع للأمر الذي فشل بعد الآن.

يمكن حل المشكلة الآن عن طريق إعادة تعيين abort_on_prompts مرة أخرى إلى False ولكن يجب القيام بذلك في كل أمر قد يفشل أو لا يفشل ،

أفترض أن الأفضل سيكون علامة لتعطيل مطالبات النسيج المضمنة تمامًا والتي من المفترض استخدامها في سطر الأوامر ، ولا سيما No hosts found.. واحد ، عند استخدام النسيج كواجهة برمجة تطبيقات. ثم abort_on_prompts لن يتسبب في SystemExit نظرًا لعدم وجود مطالبة بالتسبب في ذلك.

pkittenis في ٢ نوفمبر ٢٠١٢

+1 - أواجه هذه المشكلة بالذات الآن. حالة الاستخدام الملموسة الخاصة بي هي أنني أستخدم Fabric لإجراء فحص على العقد السحابية التي تم توفيرها مؤخرًا وتأكيد ما إذا كانت هذه العقد لديها وصول SSH باستخدام المفتاح العام المناسب. نتيجة لذلك ، أحتاج إلى التقاط استثناء abort_on_prompts بالفعل. في الوقت الحالي ، سأقوم فقط بالتقاط SystemExit صراحة ، لكن هذا يبدو خاطئًا جدًا بالفعل.

amontalenti في ٢٦ أكتوبر ٢٠١٣

+1 - أود أيضًا التقاط استثناءات abort_on_prompts.

nicholaskuechler في ٢٨ فبراير ٢٠١٤

: +1: أنا في نفس الموقف حيث لا أريد أن يتم رفع SystemExit - فهذا يقتل عمال الكرفس لدي.

tebeka في ١ مايو ٢٠١٤

في هذه المرحلة ، أشعر أن هذا المستوى من التغيير يتناسب بشكل أفضل مع الإصدار 2.0 الذي تم تصميمه مع حالة استخدام API أولاً وحالة استخدام CLI كحالة استخدام ثانوية / مجمعة. سيكون تغيير السلوك في 1.x مفاجئًا / مربكًا / قد يؤدي إلى إضافة أخطاء.

وضع علامة 2.x وتركه مفتوحًا حتى أتمكن من إعادة الزيارة والتأكد من أنني أعتبره عند كتابة هذا الجزء من API.

bitprophet في ٤ أغسطس ٢٠١٤

❤1

+1 - عندما يكون كل من abort_on_prompts و warn_only _True_ ، يجب أن يسود warn_only .
موضوع آخر حول هذه المسألة ، بقلم reeesga : https://github.com/fabric/fabric/issues/521

4hr1m4n في ٥ مارس ٢٠١٥

👍1

ybv في ١٩ يونيو ٢٠١٥

👍1

+1 - عندما يكون كل من abort_on_prompts و warn_only صحيحًا ، يجب أن تسود التحذير فقط. الإعداد الأحدث للقيام بذلك جيد أيضًا

balajijegan في ١٦ يوليو ٢٠١٥

👍1

أي تحديث على هذا ؟
لقد اكتشفت SystemExit لكنه يجعل مخرجاتي قبيحة ...

انظر بنفسك:

webapps2adm001.qa.aws.company.com: الاتصال كنجاح الجذر.
webapps2001.qa.aws.company.com: الاتصال كنجاح جذر.
خطأ فادح: مطلوب للمطالبة بالاتصال أو كلمة مرور sudo (المضيف: webapps3001.ia.aws.company.com) ، لكن الإدخال سيكون غامضًا في الوضع المتوازي
إجهاض.
webapps3001.ia.aws.company.com: فشل الاتصال كجذر. خروج النظام: 1
webapps3adm001.ia.aws.company.com: الاتصال كنجاح جذر.

أريد فقط أن أبقي على الخط بعد الإجهاض. لا أريد أن أرى رسائل الخطأ.