We would like to present our newly open-sourced ROS 2 Package Generator, simply called ros2-pkg-create. It supports C++ and Python nodes as well as advanced features such as C++ components or lifecycle nodes.
ros2-pkg-create is an interactive CLI tool for quickly generating ROS 2 packages from basic pub/sub nodes to complex lifecycle components. It is meant to replace the official ros2 pkg create command.
You can either directly control all options through command-line arguments or use the interactive questionnaire to walk through. No more memorization of available options for such a generation tool.
ros2-pkg-create can generate ROS 2 C++ Packages, Python Packages, and Interfaces Packages. The supported features include:
C++ Package: publisher, subscriber, parameter loading, launch file, service server, action server, timer callback, component, lifecycle node, docker-ros
This is great to see tools like this which help others move faster!
It would be great to get some or all of the new functionality in the official tool. Would you consider seeing how you could extend the core tool with this functionality instead of just releasing it on the side? This could help get it to more people in the long run, and make sure it stays up to date with new distros.
If you’re not interested in doing that It would be great if you would consider releasing it under an Apache-2.0 license instead of MIT so others could more easily consider doing it without mixing licensing.
As the Turtle Nest author, I’m really interested in this project. I think our projects complement each other well, and your tool provides an easy start for package creation for people who prefer CLI over GUI. I also really like that you’ve made it possible to create components and lifecycle nodes, it is something that I’ve also wanted to add as a feature.
We did initially consider to directly integrate it into the official ros2 pkg create, but wanted to avoid the risk of making the effort to only later learn whether this would have a chance of being accepted or not.
We’d be more than happy to actually contribute this into the main tool, in order to maximize impact.
For now, I would propose that I create draft pull request in the ros2cli repository with the general idea of integrating it and some first thoughts on how that could work. If we also see the support there, we can consider making the integration efforts. Sounds good to you?
Regarding the license, we’ll consider switching to Apache-2.0.
Thank you as well! Right now, I’m thinking that the package generation based on a templating engine such as Jinja (e.g., see this node header template) is a little superior and more flexible than your approach of generating the template right from the source code. If you were interested in putting a GUI on top of our templates, though, feel free to reach out again!
Heh yeah, Jinja is definitely the better way to go for templating I didn’t know about it until someone pointed out it in the Turtle Nest announcement post. I see it as a scalable option going forward, so I’m also considering switching to that.
This is another example of how a half-baked official implementation may block new tools and techniques, eventually leading to stagnation.
Looking closely, we see the code scaffolding Python library copier (used by the new tool) and the official custom implementation of ros2cli compete with each other. Feature and maintenance-wise, I do not think anyone can oppose to the claim that copier is superior. The library copier is a dedicated library for this purpose; but who knows when the ros pkg create mechanism was revised? (well, you can check their commit history if interested)
The only advantage of the ros2cli approach is being official. Hence, it is historical and political. Either the authors need to (1) strip down a lot of functionality if they use the ros2cli approach, (2) reimplement a lot of copier functionality for a much smaller community of ROS developers, or (3) add a dependency to copier next to the previous approach and create another burden for users who do not want this functionality. None of them is good.
Alternatively, I suggest the authors expose their templates and the copier tool directly to users instead of trying to make it a ROS tool. On GitHub, there are several copier-template libraries for many different types of projects, and ROS projects are not a snowflake here.
The typical usage would be then (after installing copier and read):
To make it official, similarly add a section to docs mentioning official/endorsed copier (or cookiecutter) templates for ROS projects. I believe this is good for the Foundation to be self-sustainable.
This way, you demonstrate a new tool (copier) to the community, which might be helpful to them in other projects, too (thank you for introducing copier to me). Your maintenance needs and responsibilities are lowered. You become an exemplar for similar needs where organizations can create their own templates without relying on your maintenance (they would rely on copier instead).
This is great to see tools like this which help others move faster! 
I didn’t know about it until someone pointed out it in the Turtle Nest announcement post. I see it as a scalable option going forward, so I’m also considering switching to that.