Re-spawn a process only if returncode != 0

[lukicdarkoo]

I believe there is a missing condition returncode != 0 when respawning a process. I have a process that finishes cleanly after a short time, but the launcher keeps respawning it. With the condition (returncode != 0) it works fine.

[hidmic]

@lukicdarkoo I see you use respawn as means to retry on failure. I could argue that someone may want to use respawn to keep some process alive no matter what (current behavior in master), or to reset some process' state so long as it exits gracefully (opposite to the behavior in this patch).

With that in mind, I'd suggest we add support for a condition to respawn in addition to plain booleans, instead of hard-coding this check. @ivanpauno @wjwwood for feedback.

[hidmic]

@lukicdarkoo hmm, false is not a valid Python literal.

[lukicdarkoo]

Probably not the best way to make it crash :) I will change it

[hidmic]

@lukicdarkoo have you considered:

With that in mind, I'd suggest we add support for a condition to respawn in addition to plain booleans, instead of hard-coding this check.

?

[lukicdarkoo]

@lukicdarkoo have you considered:

With that in mind, I'd suggest we add support for a condition to respawn in addition to plain booleans, instead of hard-coding this check.

?

Sounds very good to me, but I understood that @ivanpauno and @wjwwood have to agree or contribute to the idea?

[ivanpauno]

With that in mind, I'd suggest we add support for a condition to respawn in addition to plain booleans, instead of hard-coding this check. @ivanpauno @wjwwood for feedback.

Sounds fair, but how do you get the return code in the condition?

[hidmic]

Sounds fair, but how do you get the return code in the condition?

Hmm. Didn't put a lot of thought to it. Temporarily pushing it to context.locals is one option.

[ivanpauno]

Hmm. Didn't put a lot of thought to it. Temporarily pushing it to context.locals is one option.

That works, but it's really weird IMO.
I would rather let the user pass a callback which takes the return code as its only argument.
We could also accept a two arguments version, where the second one is the context, though I don't think that's really useful.

[hidmic]

I would rather let the user pass a callback which takes the return code as its only argument.

Right, but that'd make it impossible to leverage the feature from non-Python launch files.

I'm onboard with accepting callbacks for user convenience, but we have to accept a condition as well i.e. a construct that actually lives in launch conceptual domain.

[ivanpauno]

Okay, pushing it to context.locals sounds fair to me.

[wjwwood]

Okay, pushing it to context.locals sounds fair to me.

Same.

[hidmic]

@lukicdarkoo will you be moving forward with this?

[hidmic]

@lukicdarkoo friendly ping