ros2/rosidl_python

Dependency cycle between this repository and rcl_interfaces

nuclearsandwich opened this issue · 8 comments

With the introduction of the rosidl_runtime_py package there is a dependency cycle between this repository and ros2/rcl_interfaces by way of ros2/rosidl_defaults

To make the first Dashing pre-release I have temporarily ignored the rosidl_runtime_py package in order to allow release of rosidl_defaults and rcl_interfaces but it might be worth splitting the runtime package into a separate repository to avoid this issue.

Maybe I don't understand the cycle, but would removing rosidl_runtime_py's dependency to test_msgs resolve this issue? I plan to do some refactoring as part of ros2/rcl_interfaces#58 and it looks like removing the dependency to test_msgs shouldn't be too difficult.

Maybe I don't understand the cycle

Bloom releases by default(1) release every package in the repository together. This means that it's possible to create a cycle between repositories. In this case:

So before being able to release this repository via bloom, we need to release rcl_interfaces, but before that, we need to release rosidl_defaults, but before that we need to release... this repository.

would removing rosidl_runtime_py's dependency to test_msgs resolve this issue?

I think that it would. Another option would be to split rosidl_runtime_py into its own repository that can be released independently of the repositories that depend on it as we did for the vendor typesupport packages: rosidl_typesupport_{connext,fastrtps,opensplice}.


(1) It's possible to ignore a package during release but this requires adding an file to the release repository, then editing it to unignore the package which is somewhat cumbersome. It also means you have to remember the cycle and how to break it for each new rosdistro you release the interdependent repositories into.

Thanks for the detailed explanation 😃

@jacobperron we resolved this right?

I don't think so...

<test_depend>test_msgs</test_depend>

I think I thought it would get resolved during some refactoring of test interfaces, but I guess not. I'll take another look to see what can be done.

Other rosidl packages get around this issue by depending on test_interfaces_files and generating their own test messages (instead of depending on test_msgs). But rosidl_runtime_py is a pure Python package, so we'd have to make it a CMake package if we want it to generate test interfaces, AFAIK.

But rosidl_runtime_py is a pure Python package, so we'd have to make it a CMake package if we want it to generate test interfaces, AFAIK.

Or create a separate ament_cmake sibling package with the required interface files.

I'm proposed moving rosidl_runtime_py to a separate repo: https://github.com/ros2/rosidl_runtime_py

Seems to be the easiest thing to do.