ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Questioning the file extension


@wjwwood Presented the new Python-based launch files at ROSCon.

I really like the idea of using Python as a configuration/launcher language. In fact, we have also done this in the Machinekit project for both configuration and launch files.

However, what I want to question is the file extension.

Why? Python forbids adding dots in the name of a module (see Therefore, it isn’t possible to use files with extra dots in the name as if they are Python modules.

Of course, our launch file is not a Python module per default. However, it’s very likely that the launch files will be used to build modular setups. Therefore, the launch file should be treated as a normal Python module.

As a software engineer, I want to be able to test my code, this includes launch files. But it turns out quickly that this is a lot harder to do when a module can’t be imported the “normal” way via import. Other Python development tools might choke (or throw warnings) as well on the non-standard file extension.

One workaround is to use importlib. But I argue that this adds unnecessary complexity to the setup.

Therefore, I would like to propose to use a different method for identifying launch Python files such as for example using in the name.


I was trying to approximate the .launch extension that we had in ROS 1 (which would have contained XML). When people wanted to compose a launch file out of XML files they would use .xml for the parts, indicating that the .launch files were actually viable entry points for launching.

The was a way to imply it was both an entry point and clue editors to the markup of the contents. It is currently completely optional and is only considered with tab-completion.

I had imagined that people who wanted to unit test their python code used in launch files would place testable code in .py files and have a single that uses the code in the .py files to return the launch description. I have also imagined that if you wanted to do an integration test where you actually instantiate the launch file for introspection or launching you’d do that with the launch API (which handles imports for you).

For general purpose composition (a launch file including another launch file) that can (and probably should be) done with the IncludeLaunchDescription action in launch.

To alleviate other use cases we could expose the importlib logic used in launch itself to handle the suffix.

That all being said, while I prefer the aesthetics of, I would be fine with canonicalizing or something else and I’m interested in hearing from others on the topic.


Good point. Ability to embed as a python module should be considered in the file name syntax, otherwise you’ll have to un-natural things.


Just my 2 cents but I agree with @machinekoder. We’re using the “_launch” naming in Navigation2 because of this.


Thank you for the explanation.

Using importlib or to implement the code to test inside a Python module is indeed possible.

However, I still prefer the suffix, since this would conform to pep naming and enable unit tests without creating additional Python modules.

I would also be interested to hear from users that moving from ROS1 to ROS2 if the syntax feels unnatural compared to or the other way around.


If anyone has an opinion about this please speak up.

In the meantime, I’d say feel free to use and we can add it as a cue for tab-completion as well.

Finally, the only thing to decide is which extension to recommend in our documentation and tutorials.


Is there a current working example of this we can look at and try out?
I’d like to see how this all fits with composition of launch files.


To me conforming to PEP naming is a pretty strong argument, so I’d suggest to use also in documentation and tutorials.


When the naming is being decided it should also be considered how to name launch files used for testing (named .test in ROS 1).


I always wondered why they have a different naming compared to standard .launch files.


That’s useful for tab completion, among other things. You usually don’t want the test files to show up during autocomplete.