ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Questioning the .launch.py file extension


#1

@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 .launch.py file extension.

Why? Python forbids adding dots in the name of a module (see https://www.python.org/dev/peps/pep-0008/#package-and-module-names). 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 _launch.py in the name.


#2

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 .launch.py 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 .launch.py 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 .launch.py suffix.

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


#3

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.


#4

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