Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ros2pkg] Integrate features of 3rd-party ros2-pkg-create CLI tool #948

Draft
wants to merge 1 commit into
base: rolling
Choose a base branch
from

Conversation

lreiher
Copy link

@lreiher lreiher commented Nov 20, 2024

We have recently open-sourced our own package generation tool ros2-pkg-create. Please also see my introductory post on ROS Discourse.

I'm opening this draft PR in response to @tfoote suggesting to integrate ros2-pkg-creates features into the official CLI.

Note

This PR is not carrying any changes just yet. I'm mainly opening this to share some insights into the features of ros2-pkg-create, how it's different than this repository's ros2 pkg create, and how an integration here could look like. Ideally, we could gather some feedback and suggestions before starting the actual integration efforts.


Features of ros2-pkg-create

  • templates for three types of packages
    • C++ Package
    • Python Package
    • Interfaces Package (msg, srv, action)
  • support for basic and advanced features for both C++ and Python
    • publisher
    • subscriber
    • parameter loading
    • launch file (py/xml/yml)
    • service server
    • action server
    • timer callback
    • C++ component
    • C++ lifecycle
    • docker-ros
  • interactive CLI questionnaire for options not specified as CLI arguments

image

Technical Details of ros2-pkg-create

Differences between ros2-pkg-create and ros2 pkg create

  • ros2 pkg create uses empy instead of jinja, see example header
  • ros2 pkg create-only features:
    • setting dependencies via CLI arg
    • choosing C++ node vs library
    • choosing cmake vs ament_cmake build types
  • ros2-pkg-create-only features:
    • interactive questionnaire for options not via CLI arg; can also use defaults, though
    • generation of more than a barebones C++/Python node, see list of features above (e.g., publisher, launch file, action server, etc.)
    • generation of an interfaces package

@clalancette
Copy link
Contributor

So I would absolutely love to get some of these features into ros2 pkg create.

That said, I think we have to come to an agreement on the templating engine before we do anything. In ros2 pkg create, we currently use empy. I know that your ros2-pkg-create uses Jinja currently. I'd really, really prefer to keep using empy, because that is what we have "standardized" in ROS for our templating engine. Would you be willing to make changes to use empy rather than Jinja?

@lreiher
Copy link
Author

lreiher commented Nov 20, 2024

I definitely see your point regarding empy, but the limitation on our side is that copier is based on Jinja. We see the copier integration, which provides the interactive questionnaire, as one of the core features that we wouldn't want to drop.

Taking this a step further, one could of course try to bring empy support to copier. This is out of scope of what we could contribute, though.

On the other hand, we could translate the Jinja templates to empy templates (I guess this should be pretty straighforward?), add some CLI arguments here, and be done with it. To me, this integration wouldn't feel complete, though, and we would need to think about how much effort we would want to put into this from our side. We would definitely be open to someone else porting the templates, though.

@clalancette
Copy link
Contributor

On the other hand, we could translate the Jinja templates to empy templates (I guess this should be pretty straighforward?), add some CLI arguments here, and be done with it. To me, this integration wouldn't feel complete, though, and we would need to think about how much effort we would want to put into this from our side. We would definitely be open to someone else porting the templates, though.

Yeah, this is the kind of thing I would suggest here. We'd have to do this anyway, because it is far easier to get things in one-at-a-time rather than as a giant chunk of work. I'm not sure if you are up for doing that, but this is what I would suggest at least as a starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants