An idea: ros2cli extension to install remote packages

1

Hi, community,

I’ve been using ROS2 for a while, I’m using a Linux distribution with a different package system from apt or dnf, so I’m not able to install ros2 packages from the packages index with just a line of apt/dnf install command.

So I’m just wondering if we should have a ros2cli extension(like ros2 install pkg_name) to do the manual source code installation of packages. It clones git repo into a specific workspace, runs colcon build, then we can sources the setup.bash in that workspace. What’s more, the command can receive git repo in different protocols, branches or even accpet a http url, so we can track the latest or specific updates of the pacakges.

I’m now having a test on this, thanks to Python’s package entrypoint mechaism and ros2cli’s support, it’s pretty easy to make ros2 install command possible. But I would like to hear from the community, would this help the developers? At least it helps me to save some time and provide a way to get ros packages for non debian/fedora distributions.

1 Like
2

With ros-get you can do exactly this for ros1: ros-get install pkg_name. Not sure about ros2 though, perhaps with some small improvements ros2 support can be added.

3

I think thats a fabulous idea and I’m happy you’ve taken the initiative to prototype it. Adding that as another verb would add some completion of the lifecycle of pkg operations using ros2 verbs.

+1

4

hmmm, I didn’t like to blowup ros2 cli…
It’s a typical job of ansible.
I use it for years to keep targets up-to-date

5

Thanks, I’ll look into ros-get, there should be points that we can refer to.

6

Exactly, and it’s what I’m now trying! :grinning:

7

I’ve heard of ansible which should be a super generic tool for automation, do you have any articles or tutorials about how you use ansible on ros packages? I would like to have a try!

8

check this: https://github.com/jalessio/ansible-role-ros

ansible is sooo easy to use…

create an inventory file with your targets
[ros2]
nuc3 ansible_host=10.11.101.67 ansible_user=xadmin aptproxyurl=http://192.166.253.185:9999

[ros1]
NUC1 ansible_host=10.11.127.191 ansible_user=xadmin aptproxyurl=http://192.166.253.185:9999
NUC2 ansible_host=10.11.127.192 ansible_user=xadmin aptproxyurl=http://192.166.253.185:9999

now exchange ssh keys with targets
write a small yaml file with actions like:

  • name: Copy sudoers file
    copy:
    src: ./files/ros
    dest: /tmp/
    owner: ros
    group: ros
    mode: 0644

  • name: Install mandatory packages
    apt: pkg={{ item }} state=installed
    with_items:

    • aptitude
    • python-minimal

  • name: apt update
    apt:
    update_cache: yes
    cache_valid_time: 3600

  • name: apt upgrade
    apt:
    upgrade: safe

  • name: Install core basic packages
    apt: pkg={{ item }} state=installed update_cache=true
    with_items:

    • wget
    • vim
    • emacs

Enjoy always clean environments :slight_smile:

9

There’s definitely space for improving the workflow of installing ROS packages from source. However one of the tenents that we’ve worked on in the design of the ROS tools is that we want to keep different aspects separated. In particular there’s a distinction between tools that install system packages, tools that interact with source checkouts, and tools that relate to the runtime. Historically that’s, rosdep, rosinstall_generator / vcs / wstool / catkin, and the runtime tools rosmsg rossrv. In ROS 2 it’s now rosdep, rosinstall_generator & colcon, and ros2.

The ros2 command aggregates many of the runtime tools into one entry point to aid discoverability and usability.

Keeping the separation is valuable because they require different levels of access and have different levels of impact. Runtime tools generally only effect the running system and leave the system reproducible if you stop everything and restart. Similarly they also don’t require write access to your installation.

Tools to install and manipulate your workspace require write access to the workspace and change content run to run. Also if you checkout code you also need to compile and manage the workspace versions and overlays.

The third layer is the system dependency management. This requires even more access(generally sudo) to do system package installations. And it has an even broader field of effect, with it changing the behavior for all users on the system.

The tools are also deployed in different manners and need to be available at different times in the development cycle. The source workspace management tools need to be available prior to having a workspace available. Whereas the runtime tools need to be available in an active installation at runtime.

So I’d encourage you to consider improvements to the source control workflows but I would at the same time suggest not trying to tie it into the runtime command line interface. There have been several iterations of workspace management tools but much of what we’ve ended up with are the smallest atomic elements of functionality that allows users and developers to put them together in the manner that best suits them following the unix model. This is how many of the new IDEs can leverage the standalone tools and libraries to support ROS workspaces. Many IDEs can also interact with source control and depending on what your use cases are that might be another area of extension that would be valuable to explore this sort of functionality.

1 Like
10

Thanks, Tully. The separation of tooling is definitely a smart design. Indeed what I’m doing is exactly to integrate some of the workspace management functionalities to make it easier for source installation, which should be separate from runtime tool ros2. Is there some articles or docs about the source workspace management tooling or functionalities? I would like to make some exploration and see if I can come up with something useful.

11

Oops, my stupid. I read rosinstall_generator wiki and see the related tool rosinstall, roslocate. I’ll follow the path, let me know if there are more related packages I should take care of.

12

The primary tools used now in ROS 2 are rosdep, rosinstall_generator and vcstool

Here’s a few pointers for your research.

There was an exploration of modernizing rosdep with an improved UI that didn’t have enough support to finish. You can see it on github here:

There’s also several older ROS 1 specific tools that are used including rosinstall and vcstools and wstool.

13

Thanks, I looked into the tools rosinstall_generator, rosinstall, rosws, vcstools, wstool, etc., these tools together should cover my original idea. Btw, I’m curious why all the beginner tutorials just told me to create a ws folder and do everything manually, even though there is a tool chain to do that in a solid way.