Fabric: 'abort_on_prompts' anula warn_only = True
Intentar usar abort_on_prompts y warn_only = True hace que abort_on_prompts anule warn_only y la tela aún arroja un SystemSalir
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.
pkittenis
Todos 12 comentarios
(Protip, use el enlace "Github Flavored Markdown" arriba de los campos de texto, le mostrará cómo formatear las cosas correctamente. Se corrigió su descripción :)
Yo diría que, en la mayoría de los casos, cuando los usuarios alternan abort_on_prompts , probablemente_ están esperando el comportamiento actual (abortar) y no una advertencia y continuar. warn_only=True generalmente se aplica a qué hacer cuando _el programa remoto_ tiene una falla, frente a la propia tela que aborta.
Sin embargo, reconozco que esta situación en la que ambos son verdaderos no está bien definida / documentada. Además, la mayoría de los otros usos de abort() en la base de código se han reemplazado con llamadas a error() que es lo que maneja la lógica "cancelar si warn_only=False ".
Haré la llamada por ahora que la coherencia supera la posibilidad de que un usuario intente abortar en las solicitudes y se vea frustrado por un warn_only=True inesperado, y hará el cambio que está solicitando. Sin embargo, si otras personas vienen quejándose, te pondré al frente;)
bitprophet
en 29 oct. 2012
Reflexionando, estoy realmente desgarrado por esto; Puedo ver que el cambio arruina las cosas para los usuarios que, como se mencionó, realmente quieren que Fabric explote ante indicaciones inesperadas. Los errores ocultos pueden ser increíblemente frustrantes de rastrear.
@pkittenis - ¿En qué situación del mundo real te encuentras donde esto es un problema para ti? ¿Podrías usar try/except SystemExit para solucionarlo?
Si está bloqueado por esto, lo que podría tener más sentido es agregar una nueva opción de configuración (con un nombre tonto como warn_trumps_abort quizás) para que las personas en su caso de uso puedan controlar el comportamiento, sin causar un cambio inesperado para los usuarios actuales.
bitprophet
en 29 oct. 2012
El problema es que el comportamiento de abort_on_prompts hace que la tela lance un SystemSalir cuando vuelve a No hosts found. Please specify (single) host string for connection: cuando un comando tiene un error.
Cuando se usa fabric como API, eso es simplemente incorrecto en mi opinión. El usuario de la API ya ha configurado warn_only para evitar una salida del sistema en la ejecución y, en su lugar, poder manejar códigos de retorno dentro del código. Genial.
Luego, el usuario establece abort_on_prompts y en lugar de obtener el código de error para su comando cuando falla, obtiene un SystemSalir debido al retroceso a enter a host y al uso de abort_on_prompts . Puede manejar la excepción, claro, pero en ese caso ya no puede ver el código de retorno del comando que falló.
Puede solucionarse por ahora restableciendo abort_on_prompts nuevo a Falso, pero eso debe hacerse en cada comando que puede fallar o no,
Supongo que lo mejor sería una bandera para deshabilitar completamente las indicaciones de fabric integradas que están destinadas a usarse en la línea de comando, particularmente el No hosts found.. one, cuando se usa fabric como API. Entonces abort_on_prompts no causaría una salida del sistema ya que no hay un mensaje que la provoque.
pkittenis
en 2 nov. 2012
+1 - Me estoy encontrando con este mismo problema en este momento. Mi caso de uso concreto es que estoy usando Fabric para verificar los nodos en la nube aprovisionados recientemente y confirmar si esos nodos tienen acceso SSH con la clave pública adecuada. Como resultado, necesito en realidad _capturar_ la excepción abort_on_prompts. Por ahora, solo voy a capturar explícitamente SystemSalir, pero esto se siente muy mal.
amontalenti
en 26 oct. 2013
+1 - También me gustaría capturar las excepciones abort_on_prompts.
nicholaskuechler
en 28 feb. 2014
: +1: Estoy en la misma situación en la que no quiero que se recaude SystemExit ; mata a mis trabajadores de apio.
tebeka
en 1 may. 2014
En esta etapa, creo que este nivel de cambio encaja mejor en la versión 2.0, que se está diseñando con el caso de uso de API primero y el caso de uso de CLI como caso de uso secundario / contenedor. Cambiar el comportamiento en 1.x será demasiado sorprendente / confuso / susceptible de agregar errores.
Etiquetar como 2.xy dejar abierto para poder volver a visitarlo y asegurarme de considerarlo al escribir esa parte de la API.
bitprophet
en 4 ago. 2014
+1 - cuando tanto abort_on_prompts como warn_only son _Verdadero_, warn_only debe prevalecer.
Otro hilo sobre este tema, por @reeesga : https://github.com/fabric/fabric/issues/521
4hr1m4n
en 5 mar. 2015
+1
ybv
en 19 jun. 2015
+1: cuando tanto abort_on_prompts como warn_only son True, warn_only debería prevalecer. Una configuración más nueva para hacer esto también está bien
balajijegan
en 16 jul. 2015
Algún avance en esto ?
Atrapé SystemSalir pero solo hace que mi salida sea fea ...
Véalo usted mismo:
webapps2adm001.qa.aws.company.com: Conexión como root SUCCESS.
webapps2001.qa.aws.company.com: Conexión como root SUCCESS.Error fatal: necesario para solicitar una conexión o contraseña sudo (host: webapps3001.ia.aws.company.com), pero la entrada sería ambigua en modo paralelo
Abortando.
webapps3001.ia.aws.company.com: Error en la conexión como raíz. Salida del sistema: 1
webapps3adm001.ia.aws.company.com: Conexión como root SUCCESS.
Solo quiero mantener la línea después de Abortar. No quiero ver los mensajes de error.
ocervell
en 16 mar. 2016
También me encuentro con este problema y me encantaría ver cómo cambia el comportamiento actual.
mitcharf
en 29 abr. 2019
Temas relacionados
harobed
·
5Comentarios
haydenflinner
·
5Comentarios
peteruhnak
·
6Comentarios
jamesob
·
3Comentarios
acdha
·
4Comentarios