Non standard msg modules #735
Conversation
|
@zflat At the risk of sounding like I'm answering your question by saying "why don't you do it the default way ever other package does it" - I am wondering what pushed you to need the custom submodule naming? You can already control the package name and the message names; does the submodule name get you additional naming that is necessary? |
I am not the author of the messages package that I need to interface with. Also, the code I am adding is not complex and it makes less assumptions than the "only one way to do it" approach. |
|
@amacneil Can I please get a review of this bug fix? |
|
@jtbandes Is the rolling CI failure a known issue? LGTM otherwise. |
|
Rolling should be fixed if you rebase on #746 |
zflat
force-pushed
the
non_standard_msg_modules
branch
from
31566ea
to
fb5aeff
Compare
|
@defunctzombie @jtbandes I rebased and pushed but there still is a failure in CI. I have seen that failure in other recent CI builds but it seems to be an intermittent failure. |
This is a bug fix relating to parsing the python module and class names of message and service type strings when non-standard submodule naming is used. I have an application that has generated messages in a namespace that is not msg. For example, I want to subscribe to a message type 'my_package_interface/msg_core/MyMessage'. However, the ros_loader.py method _get_msg_class discards submodule information 'msg_core' and assumes the subname will be named 'msg' causing an InvalidModuleException to be raised. I like that the message type parsing is flexible and able to accommodate ROS1 style types that don't have a submodule subname in the type string. However, I think that logic is too strict because it assumes the submodule subname and prevents any naming other than msg. Note that I am trying to use the term "submodule" as it is used in https://docs.python.org/3/tutorial/modules.html even though it could be confused with git submodule. Co-authored-by: William Wedler <william.wedler@resquared.com>
Public API Changes
None
Description
This is a bug fix relating to parsing the python module and class names of message and service type strings when non-standard submodule naming is used.
I have an application that has generated messages in a namespace that is not
msg. For example, I want to subscribe to a message type'my_package_interface/msg_core/MyMessage'. However, theros_loader.pymethod_get_msg_classdiscards submodule information'msg_core'and assumes the subname will be named'msg'causing anInvalidModuleExceptionto be raised.I like that the message type parsing is flexible and able to accommodate ROS1 style types that don't have a submodule subname in the type string. However, I think that logic is too strict because it assumes the submodule subname and prevents any naming other than
msg.Note that I am trying to use the term "submodule" as it is used in https://docs.python.org/3/tutorial/modules.html even though it could be confused with
git submodule.