Add option to set output_format via environment variable

[SammyRamone]

This PR would close #664

I used a constant to get the default value instead of self.__init__.__defaults__[6] since adding any further arguments would break the code in that case.
Any feedback is welcome.

[wjwwood]

This lgtm, though I would like to see additional documentation about this in the doc block, specifically about the existence of the env var and that passing a local argument for this will still override the env var.

[SammyRamone]

Sorry for the delay, I was on a short vaccation.
As stated in my reply above, I changed the implementation so that the envvar overrides the everything.
I also added a small note in the doc string.

[clalancette]

Personally, I think that this should be done differently, and more flexibly. What I think should happen here is:

1. If the environment variable is not specified and the user passes nothing in for output_format, we use the default ([{this.process_description.final_name}] {line}). This preserves existing behavior.
2. If the environment variable is specified, we use that as the default instead.
3. But if the user passes in output_format, that overrides the environment variable (or the default).

That way a user can use the environment variable to set all of the nodes to a particular format, but then have a single node where they do something else.

If we do this, I also think that the environment variable name should change to something like ROS_LAUNCH_OUTPUT_FORMAT.

Thoughts?

[wjwwood]

@clalancette's proposal is fine with me.

If we wanted to be really thorough, we could have what you suggest as well as an "override" env var which let you explicitly set it even if something else has been set in the code. This would be just for debugging situations I guess. But doing just what you suggested is sufficient probably.

[SammyRamone]

I changed the PR to the the proposed priority ordering of @clalancette. Please re-review it.

[SammyRamone]

friendly ping @clalancette
I also fixed a missing sign off in the last commit.

[SammyRamone]

I also added a draft PR for documenting this PR ros2/ros2_documentation#4061

[SammyRamone]

friendly ping @fujitatomoya @wjwwood

[SammyRamone]

friendly ping @wjwwood @fujitatomoya
I would be happy to get this finally merged to be able to merge ros2/ros2_documentation#4061
As far as I can see it the failing check is a problem of Jenkin itself with some missing flake8 package.

[SammyRamone]

I would be really happy if we could move this PR forward. Its been almost a year since I created it.

[SammyRamone]

Can we somehow get forward with this PR, please? @wjwwood @fujitatomoya @adityapande-1995 @methylDragon @clalancette

[SammyRamone]

The failing checks are just an issue from the CI and I don't know why it says "changes requested", as I incorporated all changes that were requested. As far as I see, this PR is ready to merge. It just needs someone to give it another review. This PR also still blocks ros2/ros2_documentation#4061
@wjwwood @fujitatomoya @adityapande-1995 @methylDragon @clalancette

[fujitatomoya]

The docstring says default is ROS_LAUNCH_OUTPUT_FORMAT, but here says [{this.process_description.final_name}] {line}? these comments are confusing for me.

As user perspective if they use ROS_LAUNCH_OUTPUT_FORMAT, that should be able to override the setting in the implementation. i think that what environmental variables does usually, so that they do not change the implementation at all.

so i would suggest that,

1. ROS_LAUNCH_OUTPUT_FORMAT
2. argument to the function.
3. falls back to the default value [{this.process_description.final_name}] {line}

what do you think?

CC: @wjwwood

[SammyRamone]

The docstring means that the default can be choosen by ROS_LAUNCH_OUTPUT_FORMAT. If it is not set it will fallback to [{this.process_description.final_name}] {line}. I see that it is confusingly written. I can adapt this, however we should first decide on the other question of the priority ordering.

The order or priorities was especially requested this way by @clalancette in this comment
I personally don't care if the environment variable or the function argument has a higher priority. I can understand both sides.
@wjwwood also proposed here to have an additional env var which overrides everything. I did not add it as I thought it might be a bit too much complexity. But if you would prefere it, I could change it. Then the priorities would be

1. ROS_LAUNCH_OUTPUT_FORMAT_OVERRIDE
2. argument of the function
3. ROS_LAUNCH_OUTPUT_FORMAT_DEFAULT
4. [{this.process_description.final_name}] {line}

Would you prefer this solution?

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/better-console-logging/44012/1

[cosmicog]

Very nice contribution @SammyRamone. Making launch respect some configurations. 🙃

I think many people would love this feature. Not every launch file contains multiple nodes, and a cleaner output would let users decide on how things are displayed. RCUTILS_CONSOLE_OUTPUT_FORMAT exists for a reason. I’m already using it with ROS_LAUNCH_OUTPUT_FORMAT set to {line} in my local launch fork, and it gives me more terminal space for custom outputs.

Without this feature (or without creating bash scripts and ros2 runs in them), my table would look something like this:

[diagnostics.py-1]: +----------------+-----------+-----------+-----------+
[diagnostics.py-1]: | Module         | Status    | Temp (°C) | Voltage(V)|
[diagnostics.py-1]: +----------------+-----------+-----------+-----------+
[diagnostics.py-1]: | Motor Ctrl A   | OK        | 46.3      | 24.1      |
[diagnostics.py-1]: | Motor Ctrl B   | OK        | 46.0      | 24.1      |
[diagnostics.py-1]: | Motor Ctrl C   | OK        | 45.6      | 24.0      |
[diagnostics.py-1]: | LIDAR Unit     | WARN      | 51.7      | 11.9      |
[diagnostics.py-1]: | IMU Sensor     | OK        | 38.5      | 5.0       |
[diagnostics.py-1]: | Power Board    | FAIL      | 72.4      | 23.7      |
[diagnostics.py-1]: +----------------+-----------+-----------+-----------+

Not every robot has a screen. Some have LEDs, and some don’t even have LEDs 🙃