Recently I started working with ament_python packages and I was astonished by the complexity of the bootstrapping code/files needed.
Just to list a few:
the need for creating an empty file resource/<package_name>
the need for having setup.cfg with strictly required content
the need for repeating many information from package.xml in the setup.py (package name, version, description, maintainer, authors, …)
the need for adding (deprecated) data_files entries in setup.py
the need to define nodes as entry_points in setup.py
the need to copy test file templates just for the sake of being able to test pep compliance, copyright etc. (this is a big one I’d say!)
I’ve posted this question on RSE a week ago, but apparently it did not raise any views there, so I’m reposting here because I think this is a kind of meta question, probably targeted at the ROS PMC or the core developers team.
I’d still keep the discussion on RSE, so I won’t repost the whole question here, just the core of it:
Why is there no support library (e.g. ament_python_simple) that would automate most of these boilerplate tasks? Are there technical reasons? Or just lack of devs? Are there any community alternatives?
Thanks anyone for stopping by at the RSE question and sharing your ideas
Thanks for bringing up an important topic! Package creation is one of the first topics new ROS users usually start with, and it can be very discouraging if the process is tedious, confusing and includes many steps that are prone to errors.
The issues you raised are definitely something that should addressed by the core team. But since you asked about the community alternatives, I just wanted to bring to your attention Turtle Nest tool, which I’ve been developing to simplify the package creation process and make it more informative using GUI. To me, it’s interesting to hear about the different types of struggles in package creation, to see if some of them could be addressed with Turtle Nest.
Thanks, I’ve already used Turtle Nest and it is nice What I was missing is the option to create an interface- (message-) only package. I think this is also a quite common task.
A good alternative to ament_python is writing your package with ament_cmake_python. With your cmake you need to install the python node & package in the correct spot, but other than that its pretty clean and no duplicated info.
Yes, I know about this possibility. However, it kind of defeats the reasons why ament_python package types were created - to be able to use language-native packaging… And CMake is definitely not Python-native…
