Fabric: abort_on_prompts переопределяет warn_only = True

(Совет, используйте ссылку «Github Flavored Markdown» над текстовыми полями, она покажет вам, как правильно форматировать вещи. Исправлено ваше описание для вас :))

Я бы сказал, что в большинстве случаев, когда пользователи переключают abort_on_prompts , они _ вероятно_ ожидают текущего поведения (прерывание), а не предупреждения и продолжения. warn_only=True обычно применяется к тому, что делать, когда _ удаленная программа_ имеет сбой, в отличие от самой фабрики, которая прерывается.

Однако я признаю, что эта ситуация, когда оба варианта истинны, не определена / не задокументирована должным образом. Кроме того, большинство других применений abort() в кодовой базе были заменены вызовами error() что и обрабатывает логику «прервать, если warn_only=False ».

Сейчас я скажу, что согласованность превосходит вероятность того, что пользователь попытается прервать выполнение запросов и столкнется с неожиданным warn_only=True , и внесет запрашиваемое вами изменение. Если придут другие люди, я выставлю вас впереди;)

Поразмыслив, я действительно разрываюсь на этом; Я вижу, что это изменение портит ситуацию для пользователей, которые, как уже упоминалось, действительно хотят, чтобы Fabric взорвалась при неожиданных запросах. Выявление скрытых ошибок может быть невероятно трудным.

@pkittenis - с какой реальной ситуацией в мире вы try/except SystemExit чтобы обойти это?

Если вы сильно заблокированы этим, возможно, имеет смысл добавить новый параметр конфигурации (с каким-то тупым именем, например, warn_trumps_abort возможно), чтобы люди в вашем варианте использования могли контролировать поведение, не вызывая неожиданных изменений. для текущих пользователей.

Проблема в том, что поведение abort_on_prompts заставляет фабрику выдавать SystemExit, когда она возвращается к No hosts found. Please specify (single) host string for connection: когда команда имеет ошибку.

Когда вы используете ткань в качестве API, это неверно, ИМО. Пользователь API уже установил warn_only чтобы избежать SystemExit при выполнении и вместо этого иметь возможность обрабатывать коды возврата внутри кода. Замечательно.

Затем пользователь устанавливает abort_on_prompts и вместо получения кода ошибки для своей команды при сбое получает SystemExit из-за отката к enter a host и использования abort_on_prompts . Конечно, может обработать исключение, но в этом случае вы больше не можете видеть код возврата команды, которая не удалась.

На данный момент можно обойтись, сбросив abort_on_prompts обратно на False, но это нужно делать для каждой команды, которая может или не может завершиться ошибкой,

Я полагаю, что было бы лучше всего использовать флаг для полного отключения встроенных приглашений фабрики, которые предназначены для использования в командной строке, особенно No hosts found.. one, при использовании фабрики в качестве API. Тогда abort_on_prompts не вызовет SystemExit, так как нет подсказки, чтобы вызвать его.

+1 - Я столкнулся именно с этой проблемой прямо сейчас. Мой конкретный вариант использования заключается в том, что я использую Fabric для проверки недавно подготовленных облачных узлов и подтверждения того, имеют ли эти узлы доступ по SSH с соответствующим открытым ключом. В результате мне действительно нужно _catch_ исключение abort_on_prompts. Сейчас я просто собираюсь явно перехватить SystemExit, но это действительно очень неправильно.

+1 - Еще хотелось бы перехватывать исключения abort_on_prompts.

: +1: Я нахожусь в той же ситуации, когда я не хочу поднимать SystemExit - это убивает моих рабочих сельдерея.

На данном этапе я чувствую, что этот уровень изменений лучше подходит для версии 2.0, которая разрабатывается с использованием в первую очередь варианта использования API и варианта использования CLI в качестве дополнительного варианта использования / оболочки. Изменение поведения в 1.x будет слишком неожиданным / запутанным / склонным к добавлению ошибок.

Пометить как 2.x и оставить открытым, чтобы я, надеюсь, смог вернуться и убедиться, что учел это при написании этой части API.

+1 - когда и abort_on_prompts и warn_only равны _True_, warn_only должно преобладать.
Еще одна ветка по этой проблеме от @reeesga : https://github.com/fabric/fabric/issues/521

+1

+1 - когда и abort_on_prompts, и warn_only имеют значение True, warn_only должен преобладать. Для этого подойдет и более новая настройка.

Есть новости по этому поводу?
Я поймал SystemExit, но это делает мой вывод некрасивым ...

Смотрите сами:

webapps2adm001.qa.aws.company.com: подключение с правами root УСПЕШНО.
webapps2001.qa.aws.company.com: подключение с правами root УСПЕШНО.

Неустранимая ошибка: необходимо запрашивать пароль для подключения или sudo (хост: webapps3001.ia.aws.company.com), но ввод в параллельном режиме будет неоднозначным.

Прерывание.
webapps3001.ia.aws.company.com: подключение с правами root не выполнено. SystemExit: 1
webapps3adm001.ia.aws.company.com: подключение с правами root УСПЕШНО.

Я просто хочу остаться в очереди после прерывания. Я не хочу видеть сообщения об ошибках.

Я тоже сталкиваюсь с этой проблемой и хотел бы, чтобы текущее поведение изменилось.