Why does the ROS2 Python launch files look like XML written in Python?

[wjwwood]

@sloretz

If I understand correctly, the ROS 2 Python launch files create a description of how to launch and keep the system running. The launch file themselves aren’t really what does the work of launching. Their work is over once they generate the description. It is launch that takes that description and executes it. That’s why there’s IfCondition to describe what to do if something should happen instead of a Python if to actually do it.

@sloretz is correct, this is the purpose of the Python API provided by launch, i.e. to create descriptions of what you want to do, not do it. That’s why it reads like a markup language like XML or JSON, because that’s what it was intended to do.

There’s a little bit about it here: ROS 2 Launch System

@sloretz

That’s fair criticism. I don’t find working with the Python description directly very fun either. I think the tutorials should recommend the xml frontend instead.

Agreed, that’s definitely a documentation issue. For some context, we started by only having the Python API due to time constraints, so we documented how to use it for making launch files a bit, in order to have something. Later we finished the frontends which let you use XML and YAML. I’ve always believed these should be what most people should use most of the time.

@aposhian

I think that many projects that use a structured data format for configuration (XML, JSON, YAML, etc.) eventually lead to some sort of solution to generate or template that configuration to gain more flexibility. While some may prefer this method, I personally do not. Rather than having a configuration language and a template language, I think it is better to gain the flexibility by simply putting everything into a general-purpose language like ROS2 launch does. Another example project that follows this paradigm in a similar (but not identical) way to ROS2 launch is AWS CDK , which uses general purpose programming languages versus the more traditional Cloudformation JSON/YAML templates.

I get where you’re coming from, but when doing research for ros launch in ROS 2, I evaluated this approach, and I came to two conclusions:

• First, we should follow the pattern set forth by large ecosystems like web (html + css for config + js for scripting, where our current launch frontends like XML are equivalent to html).

Separating describing what you want from actually making it happen (launching for launch, rendering for html) lets you have more standardization and also lets you have different backends, e.g. different browsers for html and different launch implementations for ROS 2 (imagine a tool that reads launch descriptions from py or xml and runs them using some OS dependent process management system).

Also, as systems get large and complex, having a separation from describing what you’re going to do and doing it let’s you debug it more easily. We haven’t yet gotten to writing those tools (the --print options is pretty naive and not super useful), but you can imagine a GUI that shows what a launch file will do and visualize it doing it as it launches, etc.

• Second, having this Python API and XML/YAML frontends does not prevent you from having a dynamic “API-like” interface for launching things.

You, or someone else, could write a Python API that works more like how you’re imaging. You’d just loose the ability to introspect it because running it is the only way to know what’s in it.

@bmagyar

I also find the python launch scripts overly complex. It’s ok and cool to give advanced options for launching things but it fails on the principle of making simple things simple to do.

I agree, but hopefully it’s clearer now, that this is not the original purpose of the launch API. I think the XML frontend does manage this, however. It could always be better of course.