Prefer package.xml in hybrid packages?

[meyerj]

The current implementation of rosdep and the underlying rospkg prefers the manifest.xml file over the newer package.xml. This is independent from whether it has been invoked with rosdep install <package> or rosdep install --from-path ....
For compatibility reasons the manifest.xml file still exists in some packages of the Orocos Toolchain (https://github.com/orocos-toolchain) as this file is also used by another build tool (Autoproj). Those packages are pure cmake packages and the package.xml was added for ROS compatibility only, as recommended for 3rd party packges released in the ROS ecosystem.

rosdep install --from-path ... only finds packages with a package.xml, but within each package it reads manifest.xml if this file exists.

Relevant code:

• https://github.com/ros-infrastructure/rosdep/blob/master/src/rosdep2/rospkg_loader.py#L120
• https://github.com/ros-infrastructure/rospkg/blob/master/src/rospkg/manifest.py#L354

The simple question is: What is the reason for rosdep's preference of manifest.xml? Is this intentionally or a leftover/regression from earlier releases?

It is hard to understand how all the tools and libraries (rosdep, rospack, catkin, rospkg, catkin_pkg etc.) are connected. Is there a consistent policy of what defines a catkin package and which tool prefers which file?

ros-infrastructure/rospkg#30 was a related discussion about compile and linker flags of hybrid packages, where the result was to prefer manifest.xml. But this one was about getting the compiler and linker flags in rosbuild and has no direct consequences for rosdep, right?

[wjwwood]

Also for reference: ros-controls/ros_control#101

[tfoote]

From rospkg#30 and linked ros/rospack#11 we chose to always prioritize dry over wet, and I believe this is consistent across all tools. (Mostly because we've worked hard to reuse code paths so all dry aware tools all bottom out at rospack.)

For this use case where dry is not included would need to propogate a flag through the code paths to avoid the preference if only one is valid. That's quite a few APIs which would need to be extended.

How is this effecting your code base? I presume that you're opening a ticket because it's presenting a problem for you.

[meyerj]

Okay, I understand. I just wanted a confirmation that this behavior is intentional.

How is this effecting your code base? I presume that you're opening a ticket because it's presenting a problem for you.

Yes, but there are ways to work around it. See orocos-toolchain/utilrb#5 for further details.

Thanks, @tfoote!