Tentar usar abort_on_prompts e warn_only = True faz com que abort_on_prompts substitua warn_only e a malha ainda lança um 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.
(Protip, use o link "Github Flavored Markdown" acima dos campos de texto, ele mostrará como formatar as coisas corretamente. Corrigido sua descrição para você :))
Eu diria que, na maioria dos casos, quando os usuários alternam abort_on_prompts
, eles estão _provavelmente_ esperando o comportamento atual (abortar) e não um aviso e continue. warn_only=True
normalmente se aplica ao que fazer quando _o programa remoto_ falha, vs o próprio Fabric abortando.
No entanto, reconheço que esta situação em que ambos são verdadeiros não está bem definida / documentada. Além disso, a maioria dos outros usos de abort()
na base de código foram substituídos por chamadas para error()
que é o que lida com a lógica "abortar se warn_only=False
".
Por enquanto, farei a convocação de que a consistência supera a possibilidade de um usuário tentar abortar nos prompts e ser impedido por um warn_only=True
inesperado e fará a alteração que você está solicitando. Se outras pessoas vierem reclamando, eu colocarei você na frente;)
Refletindo, estou realmente dividido sobre isso; Eu posso ver a mudança bagunçando as coisas para os usuários que, como mencionado, realmente querem que o Fabric exploda com solicitações inesperadas. Erros ocultos podem ser incrivelmente frustrantes de rastrear.
@pkittenis - que situação do mundo real você está enfrentando em que isso é um problema para você? Você poderia usar try/except SystemExit
para contornar isso?
Se você estiver bloqueado por isso, o que pode fazer mais sentido é adicionar alguma nova opção de configuração (com algum nome idiota como warn_trumps_abort
talvez) para que as pessoas em seu caso de uso possam controlar o comportamento, sem causar uma mudança inesperada para usuários atuais.
O problema é que o comportamento de abort_on_prompts
faz com que o tecido lance um SystemExit quando cai para No hosts found. Please specify (single) host string for connection:
quando um comando tem um erro.
Ao usar o fabric como uma API, isso é apenas IMO errado. O usuário da API já configurou warn_only
para evitar um SystemExit na execução e, em vez disso, ser capaz de manipular códigos de retorno dentro do código. Isso é ótimo.
Em seguida, o usuário define abort_on_prompts
e, em vez de obter o código de erro para seu comando quando ele falha, obtém um SystemExit por causa do fallback para enter a host
e do uso de abort_on_prompts
. Pode lidar com a exceção, claro, mas nesse caso você não pode mais ver o código de retorno do comando que falhou.
Pode contornar agora, redefinindo abort_on_prompts
volta para False, mas isso precisa ser feito em cada comando que pode ou não falhar,
Suponho que o melhor seria um sinalizador para desabilitar completamente os prompts integrados do fabric que devem ser usados na linha de comando, particularmente o No hosts found..
one, ao usar o fabric como uma API. Então abort_on_prompts
não causaria um SystemExit, pois não há prompt para causá-lo.
+1 - Estou enfrentando esse mesmo problema agora. Meu caso de uso concreto é que estou usando o Fabric para fazer uma verificação nos nós de nuvem provisionados recentemente e confirmar se esses nós têm acesso SSH com a chave pública apropriada. Como resultado, eu preciso realmente _catch_ a exceção abort_on_prompts. Por enquanto, vou capturar SystemExit explicitamente, mas isso parece muito errado, de fato.
+1 - Eu também gostaria de capturar as exceções abort_on_prompts.
: +1: Estou na mesma situação em que não quero que SystemExit
seja gerado - isso mata meus trabalhadores do aipo.
Neste estágio, sinto que esse nível de mudança se encaixa melhor na versão 2.0, que está sendo projetada com o caso de uso da API primeiro e o caso de uso da CLI como um caso de uso secundário / wrapper. Mudar o comportamento no 1.x será muito surpreendente / confuso / sujeito a adicionar bugs.
Marcando como 2.x e deixando aberto para que eu possa revisitar e ter certeza de que o considero ao escrever essa parte da API.
+1 - quando abort_on_prompts
e warn_only
são _Verdadeiros_, warn_only
deve prevalecer.
Outra discussão sobre este problema, por @reeesga : https://github.com/fabric/fabric/issues/521
+1
+1 - quando abort_on_prompts e warn_only são True, warn_only deve prevalecer. Uma configuração mais recente para fazer isso também é adequada
Alguma atualização disso ?
Eu peguei SystemExit, mas isso apenas torna minha saída feia ...
Veja por si mesmo:
webapps2adm001.qa.aws.company.com: Conexão como root SUCCESS.
webapps2001.qa.aws.company.com: Conexão como root SUCCESS.Erro fatal: necessária para solicitar uma senha de conexão ou sudo (host: webapps3001.ia.aws.company.com), mas a entrada seria ambígua no modo paralelo
Abortando.
webapps3001.ia.aws.company.com: Falha na conexão como root. Sair do sistema: 1
webapps3adm001.ia.aws.company.com: Conexão como root SUCCESS.
Eu só quero manter a linha após o aborto. Não quero ver as mensagens de erro.
Também estou enfrentando esse problema e adoraria ver o comportamento atual alterado.