-
Notifications
You must be signed in to change notification settings - Fork 35
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
manifest.xml: switch metaruby to tag type <rosdep> #140
Conversation
…e treated by rosdep Signed-off-by: Johannes Meyer <[email protected]>
Signed-off-by: Johannes Meyer <[email protected]>
This should be transparent for Autoproj, yes. It's all green on CI, so that's good for us. However, this is picking up the released version of metaruby. Even though we're trying to cleanup our act version-wise, I currently dont't guarantee that orogen master will work on metaruby gem. |
Thanks for the warning. I am going to check whether the tests pass with the latest metaruby (and utilrb?) versions from https://rubygems.org/. Do you propose another way to provide a specific version of metaruby for a specific version of orogen, for example to add tools-metaruby as a submodule to orocos_toolchain or to this repo? How does Autoproj know which version to install? On the other hand, if the versions from https://rubygems.org/ work, would you consider to remove submodule utilrb? If I understand correctly, it is not and was never really part of "the Orocos toolchain", but a dependency of orogen. |
I, and by extension Rock, has sucked at maintaining versioning. We basically have been running from master for the last few years. I'm starting an effort to properly version things, at which point it would be easier to answer this question. The closest you could get to this "workflow" is indeed to use submodules. On the Autoproj side, releases are handled by producing a consistent version file, which is usually a snapshot of the current state.
I'm not involved in the orocos-toolchain maintenance, so this is your call. But then, utilrb has the same issues than metaruby concerning "compatibility". FYI, the codegen part of the orogen test suite has been too hard to maintain, I nowadays rely on a separate Rock test suite (https://github.com/rock-core/rock.build-tests-buildconf) for everything that requires builds. I would suggest you start to do the same for the typekit-only codegen usage of orogen. The internals (non-codegen) parts is unit-tested directly. |
I was using this branch with success in a local from-source build. I've now removed the use of this branch (as it's deleted) and am now getting the error related to missing metaruby.
Maybe the solution is to merge these commits into toolchain-2.9 branch? |
Yes, likely, if you use the docker image for Orocos and ROS 2 in Ubuntu Focal built from https://github.com/orocos/orocos-docker-images/tree/master/ros2/ubuntu. There we define the rosdep keys If that would be accepted, then prereqs.yaml could be removed for the Orocos docker image. Eventually you do not need orogen, utilrb and metaruby, if you only want to use RTT and rtt_ros2_integration? Currently they are submodules of orocos_toolchain, and that is why If someone with more insights in the Ruby world can fix the issues with rosdep and with running orogen and typegen itself, and support it for ROS and orocos_toolchain users, that would be nice. Otherwise I suggest to remove the submodules starting from the next release toolchain-2.10 and on branch |
… such that it can be installed correctly by rosdep:
Without this patch:
$ rosdep install -y --from-path . --ignore-src ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies: orogen: Missing resource metaruby ROS path [0]=/build/orocos_toolchain
With this patch (on Ubuntu 18.04):
This patch effectively reverts 8cb82a5.
Background information:
Unfortunately rosdep still prefers
manifest.xml
(aka dry) beforepackage.xml
(aka wet) if it exists. Inmanifest.xml
packages listed with<depend>
must be valid ROS packages with apackage.xml
ormanifest.xml
file. In contrast,<rosdep>
dependencies are looked up in the rosdep database. rosdep also supports packages of typegem
(cf. rosdep2/platforms/gem.py) andmetaruby
is available as a gem. So with this patch and after keymetaruby
has been added to the rosdep database of ruby packages, it is possible to install all dependencies of an orocos_toolchain workspace with rosdep again for source builds.For binary releases into ROS
orogen
cannot depend on gems, andmetaruby
must be provided as a ROS package, too. That is what we did in 2014 in repo metaruby-release for the indigo release and what triggered the change in 8cb82a5. But at the moment there are no binary releases in ROS and for source builds using the gem formetaruby
is more convenient. If there would be binary ROS releases again in the future, it is possible to delete or renamemanifest.xml
in the release repository, such that bloom and other tools only consider the dependencies inpackage.xml
, where there is no distinction between ROS packages and other dependencies found via rosdep.As far as I know for Autoproj it does not matter whether dependencies are listed using tag
<rosdep>
or<depend>
, correct?In orocos-toolchain/rtt#321 it has been discussed to eventually drop
manifest.xml
completely and switch toautoproj.xml
to get rid of the ROS/Autoproj compatibility issues.In the second commit, 7a29461, I updated the maintainer email in package.xml. The domain
lists.mech.kuleuven.be
does not work anymore since the department switched to a centralized list server infrastructure at https://ls.kuleuven.be a few years ago. [email protected] currently forwards to [email protected].