Binary release - at least of the descriptions

[wxmerkt]

Hi all, Thank you very much for the recent activity and updates! We are heavy users of this package on multiple platforms (2f, 3f, force torques) and often run into the same issue: We depend on the description packages for visualisation and development machines that do not require the full control stack (as robots do, or even the simulation tack) - as this is a mono-repo our users manually need to copy the subdirectories, catkin-ignore all robot-only packages, install tons of unneeded dependencies (SOEM, CANopen etc.) or use a fork. Thus, it would be great if - if not all - some packages, especially the descriptions, could be released into the binaries.

We are happy to volunteer in maintaining and helping with the release hereto, if so desired.

Looking forward to hearing your thoughts, Wolfgang

[wxmerkt]

Hi, I'd like to follow up on this item. We'd really like to see a binary release of the description and/or drivers to kinetic/melodic. Happy to volunteer to help out with this as well.

[wxmerkt]

Hi @jproberge, We'd love to get the Robotiq descriptions (and perhaps drivers) released for Kinetic/Melodic as we have to always download the repository and remove the drivers etc. on non-robot machines (or fork and split out the descriptions). Is there anything speaking against it? I'd be happy to volunteer to help out with this as well.

Thanks, Wolfgang

[jproberge]

Hi @wxmerkt ,

I've been thinking about this for some time now and I indeed think we should definitely move on to make binary releases for our package stack. To be honest, I don't think it would be incredibly difficult to achieve that in the rather near future, at least for Kinetic and Melodic. Have you checked the Jenkins jobs? See here for yourself. There are a few warnings that make the kinetic build unstable, but these should be rather easy to fix. This could be a simple starting point.

I also share the idea that releasing descriptions and drivers separately would be great, I agree to start working on that as soon as possible. I think this step would benefit many people that sometimes have trouble installing the dependencies. Feel free to contribute as much as you want, I would review and accept any PR that would bring us closer to such releases.

All the best, jproberge

[gavanderhoorn]

@jproberge wrote:

I also share the idea that releasing descriptions and drivers separately would be great, I agree to start working on that as soon as possible.

note that Bloom does not support releasing a subset of pkgs from a repository, so if you want to do this, a new repository will have to be created.

This would seem to tie in with ros-industrial/ros_industrial_issues#49.

[wxmerkt]

Thank you @jproberge! I will follow up in this either in the next few days or first week of March.

note that Bloom does not support releasing a subset of pkgs from a repository, so if you want to do this, a new repository will have to be created.

Can't we manually specify the list in the yaml?

[gavanderhoorn]

note that Bloom does not support releasing a subset of pkgs from a repository, so if you want to do this, a new repository will have to be created.

Can't we manually specify the list in the yaml?

after Bloom has done it's job: yes, I believe so, but you would still be versioning and processing everything at the same time, as git does not support partial tagging.

I would also not recommend it tbh.

[christian-rauch]

If a partial release is not possible at this time, could we at least split the descriptions (robotiq_2f_c2_gripper_visualization, robotiq_2f_140_gripper_visualization, robotiq_3f_gripper_visualization) into separate git repos and add them as submodules to this main repo? I also would really like to use the descriptions (and maybe the message definitions) without having to download/compile the whole control+gazebo stack.

[gavanderhoorn]

I also would really like to use the descriptions (and maybe the message definitions) without having to download/compile the whole control+gazebo stack.

not a real solution, but both catkin and catkin_tools support package white- and blacklists that make it relatively easy to compile subsets of packages in a workspace. You should be able to use that as a work-around for now.

[christian-rauch]

@gavanderhoorn What do you mean with "not a real solution"? I think it should be possible to use the URDFs and meshes without the control and Gazebo stack. If the descriptions are located in their own repo, you can either A) bloom release them independently from the drivers and simulation, or B) add them as submodules and later bloom release them as part of the robotiq meta package. In any case, one will be able to just check out the description as part of a vcs tool repo file without the need to blacklist individual packages afterwards.

[gavanderhoorn]

What I posted (ie: use a black or whitelist) was not meant as a real solution. It's almost a work-around.

---

Edit: however, users don't have to compile "everything" should not be a rationale for splitting repositories. For that black and/or whitelisting are actually OK techniques.

The real solution would be to just release the packages. Then users would not have to build them from source, and we don't have this problem.

[wxmerkt]

Another work-around I frequently use: Clone the repository in a different location and symlink only the descriptions into the workspace.

I am all in favour of making a binary release and happy to volunteer to assist with it. @jproberge is there anything blocking a binary release right now?

[christian-rauch]

@gavanderhoorn I agree that blacklisting packages is not an ideal solution. That is why I am proposing to move the descriptions into their own repos and either release them independently or as a submodule of the main repo. The benefit of having modular repos is actually quite large. You can use the URDFs without having to wait for a release (e.g. on other Linux distributions or CPU architectures) and you can use them outside of the ROS ecosystem. Also, I do not see a disadvantage if the dedicated description repos are added as submodules.

[gavanderhoorn]

@christian-rauch: perhaps you're misunderstanding me. I don't need to be convinced of the benefits of splitting off drivers from description repositories. I already linked ros-industrial/ros_industrial_issues#49 which deals with this exact topic.

However, I don't believe splitting because of "not having to build everything" should be the only rationale, as there is support in tools to manage that and in addition regular users should not have to built from sources anyway.

So let's conclude that it might make sense to split out the description or driver packages and leave the logistics and decision to @jproberge.

either release them independently or as a submodule of the main repo.

let's stay away from submodules.