Feature Request: getting more out of interfaces

[julianmueller]

Hello,
I'm designing a GUI tool to inspect ros2 interfaces (in Python).

To get interface definitions, I'm mainly using get_fields_and_field_types() and SLOT_TYPES. I don't know, why things have been designed as they are, but I'd like to propose some additions/enhancements:

1. Being able to get constants. For now, I need to check all upper-cased class variables and sort out "SLOT_TYPES" to get all constants, defined in the interface definition. This could be made alot more easy by providing a function get_constants() which returns a list of all the constants defined in the interface.

2. Being able to get the raw interface definition as a string. A lot of interface definitions have more to them then constants, fields types and values. The often have comments, which describe, what the intention of a specific field is. As a start, it would be helpful to get the entire definition as a raw string.

3. Have get_fields_and_field_types() to not return only a dict that has strings as values, but the actual definitions, that are inside SLOT_TYPES. This seems a bit convoluted to me. This makes it harder to traverse through a tree of interface definitions. What is the benefit of knowing that a field type is "geometry_msgs/PoseStamped" instead of directly having the class reference there?

As I said, there might be more to it than I see right now, and I'd be happy to hear, what the reasons are behind some design decisions. Furthermore, I'd be happy to contribute code regarding these features via a PR, but I might need help that points me in the direction, where the contribution belong to.

Thanks

[mjcarroll]

1. Currently, there is an entry in the metaclass for constants, we could probably put an equivalent on in the message itself. I don't think that there would be any sort of objection here.

2. This seems reasonable, no objections here.

3. I think this is the most interesting (and potentially complicated facet). Currently, we use the strings because:

   • Avoiding circular dependencies: Directly returning class references could potentially lead to circular import dependencies, especially when dealing with nested or related interface definitions.
   • Decoupling and introspection: Returning strings allows for a more decoupled approach. The introspection logic can operate on the type names without needing to import the actual message/service/action classes immediately. This can be useful in scenarios where you might want to analyze interface definitions without necessarily having all the related packages available.
   • Serialization and representation: Type names as strings are inherently serializable and provide a consistent way to represent the field types across different parts of the system.

I think that maybe we could introduce a second parallel feature that does actually expand each field into the corresponding type, but I would be hesitant to change the current implementation for the reasons stated above.

Furthermore, I'd be happy to contribute code regarding these features via a PR, but I might need help that points me in the direction, where the contribution belong to.

Since this is largely around the python message generation, I think that the place you are looking for is : https://github.com/ros2/rosidl_python Specifically, these things are generated by rosidl_generator_py. For messages, at least, here is the template that is expanded on a per-message basis: https://github.com/ros2/rosidl_python/blob/rolling/rosidl_generator_py/resource/_msg.py.em

[christophebedard]

2. Being able to get the raw interface definition as a string. A lot of interface definitions have more to them then constants, fields types and values. The often have comments, which describe, what the intention of a specific field is. As a start, it would be helpful to get the entire definition as a raw string.

You can get the file path of an interface using rosidl_runtime_py.get_interface_path(). Then you can just read the file contents. This is for example used for the ros2 interface show command. That file also has some logic (in the InterfaceTextLine class) to be able to identify lines that are comments or have trailing comments, nested messages, etc. It might be worth moving that logic to one of the rosidl* packages. And maybe rosidl_runtime_py could have a util function to get the interface definition string directly.

3. Have get_fields_and_field_types() to not return only a dict that has strings as values, but the actual definitions, that are inside SLOT_TYPES. This seems a bit convoluted to me. This makes it harder to traverse through a tree of interface definitions. What is the benefit of knowing that a field type is "geometry_msgs/PoseStamped" instead of directly having the class reference there?

I'm guessing you're aware, but just in case you're not: you can combine a message class (obtained from the string type name) with rosidl_parser to go through a message definition/type. For example, see this part in rqt_plot. Probably not the easy-to-use solution you're looking for, though.