add ability to define and pass launch arguments to launch files

[wjwwood]

This pull request is ready for review.

To try it, you can use the example files in ros2launch, e.g.:

% ros2 launch --show-args ./path/to/ros2launch/examples/example.launch.py
...

% ros2 launch ./path/to/ros2launch/examples/example.launch.py
...

% ros2 launch ./path/to/ros2launch/examples/example.launch.py node_prefix:=foo_
...

fixes #107

[wjwwood]

@nuclearsandwich c45a877 should fix Python 3.5 support. Why it fixes it 🤷‍♂️ .

[dhood]

Why it fixes it 🤷‍♂️

I tracked this down once in the past: 72ae169#r195963696

[dhood]

edit (bad link): 72ae169#r195963696

[dhood]

github is changing my links, sorry for spam. this should work

[mikaelarguedas]

github is changing my links, sorry for spam. this should work

Yes github now perform differently if you get the comment from specific commit. Getting the comment link from the PR page should work though: #81 (comment)

[wjwwood]

Ok, this one is ready for review, CI:

• Linux
• Linux-aarch64
• macOS
• Windows

[mjcarroll]

I mentioned this directly to you, but if you run your example launch file without the demo executables available (I removed via rm -rf), the launch executable will report an error, and then go into a state where you cannot stop it, even with multiple Ctrl-C's.

I have put the output here: https://gist.github.com/mjcarroll/65ee17100613d41ea503408ba86c183e

[mjcarroll]

launched

[wjwwood]

So, I think that if you change the name of the executable that the example launch file is looking for or delete it (as you did), then you'll get the same behavior on master. So I don't really want to have to fix that on this pull request. It's already being tracked here: #112 I hope to have time to look into that tomorrow.

Can you re-review with the above in mind, only testing out the new features (passing of arguments, etc...).

[wjwwood]

The only difference with master is that I don't print out the traceback by default (only on debug), which I changed in this pr, but it still produces the same exception and runtime behavior.

[wjwwood]

I looked into it and the fix was pretty simple, so I went ahead and committed it in this pr: b4969f4

Basically that just lets already running things shutdown when an unhandled exception is received. I was never able to reproduce the "cannot even ctrl-c it" scenario, even before.

I also committed f077ab6 to avoid invalid state in the execute process action if the exception originated there (basically it registers event handlers, and then an exception occurs, making the event handlers invalid).

Also, I'd appreciate feedback on 4dbd9bb which is restoring the state of master which is that exceptions are reported as a single line and the traceback is only in the debug output.