[ros-users] [Discourse.ros.org] [General] Sharing ROS betwee…

Hey all. You've probably heard of [snaps](https://snapcraft.io/) (a new packaging format that works on a number of different Linux distributions) and [Ubuntu Core](https://www.ubuntu.com/core) (a new distribution of Ubuntu based entirely upon snaps). In case you haven't, imagine being able to create a pre-built, installable package of an entire ROS workspace with no more metadata than this:

    name: ros-example
    version: 1.0
    summary: ROS Example
    description: Contains talker/listener ROS packages and a .launch file.
    confinement: strict

    apps:
      launch-project:
        command: roslaunch listener talk_and_listen.launch
        plugs: [network, network-bind]

    parts:
      ros-project:
        plugin: catkin
        catkin-packages:
          - talker
          - listener

That's from the basic [ROS demo](https://github.com/snapcore/snapcraft/tree/master/demos/ros) contained within [Snapcraft](https://github.com/snapcore/snapcraft), the tool used to create snaps. Add one line (`daemon: simple`) to the `launch-project` object in `apps` and it would be a service, running at boot, no systemd knowledge required.

If that's new to you and you like it, cool, you can stop reading right here! But I'm writing today to let you know about something new.

One of the key tenets of snaps is that they bundle their dependencies. This is by design, and is one of the strengths of snaps, but it can be a downside as it's inflexible: ROS historically couldn't be shared between snaps. I wanted to let you know that, as of Snapcraft v2.28 (soon to be released), this will be changing.

Soon you'll be able to build snaps utilizing an underlay that comes from another snap, and utilize that underlay at runtime via what's called the `content` interface. This will allow for a few things:

- Reduce size by not requiring every ROS snap to include `roscore`, `rosrun`, `roslaunch`, and so on.
- Allow for new behaviors to be shipped in "add-on" snaps that can work together with a base platform instead of requiring that every ROS snap be standalone.

This post is already getting a bit long, but if this sounds interesting to you I wrote a [detailed article](https://kyrofa.com/posts/distributing-a-ros-system-among-multiple-snaps) outlining the rationale as well as walking through a basic example. Please do give it a try!






---
[Visit Topic](https://discourse.ros.org/t/sharing-ros-between-snaps/1529/1) or reply to this email to respond.


If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <http://lists.ros.org/mailman//options/ros-users>