@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.
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.
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.
Using importlib or to implement the code to test inside a Python module is indeed possible.
However, I still prefer the _launch.py 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 _launch.py syntax feels unnatural compared to .launch.py or the other way around.