I’d like to request for the autoconnection of the content interface (slots) provided by the snaps listed below. Those snaps all contains a set (small to large) of the ROS framework and that for different versions of said framework. They overall contain executables and libraries used at runtime by other snaps plugging to them. They are part of a larger body of work that natively enables this feature (ROS content sharing) in snapcraft (see #4221) and were developed following the model established by the KDE Framework snaps. An example of a snap using this feature can be found here.
Not sure whether I provide all the necessary info, so of course feel free to ping me.
Before proceeding, can you please rename the content attribute value of each of the snaps so then it is clear for plugging snaps what they are connecting to? e.g. I see you have the same:
After discussing with @emitorino, I’ll bring some more details to this thread.
Those snap contains sets of the ROS framework. foxy/humble/noetic are versions, quite analogous to 18/20/22. The suffixes core/base/desktop are super-sets of the framework, desktop contains base (and some) which in turn contains core (and some). All those terms are well established in the ROS project.
For a given version (say foxy), snaps are partially compatible in the sense that a ros-foxy plug expecting the core subset can connect to a ros-foxy slot on either of core/base or desktop and expect to find the bits it requires.
The inverse is not true. A ros-foxy plug expecting the desktop set will not work if connected to the ros-foxy plug on core nor on base.
This partial compatibility, and thus the naming, is meant as a feature not a bug. E.g., given several consumer snaps with different foxy plugs (core/base/desktop), rather than installing all three provider snaps, one could deploy only the greater super-set required (desktop) and connect all consumers to it.
I need to mull this over a bit to see what’s best. I’ll comeback to this thread asap .
After internal discussion we came up with the following mitigation.
Each snap would declare their specific slot, that is e.g. the ros-noetic-ros-core snap would declare a ros-noetic-ros-core slot; the ros-foxy-desktop snap would declare a ros-foxy-desktop slot.
In addition, super-set snaps would declare additional slots for the lower sets they encompass since the content of those lower sets is also present. These additional slots would also be auto-connectable. E.g. the ros-foxy-desktop snap would also declare the ros-foxy-ros-base & ros-foxy-ros-core slots.
A full example for the foxy version is,
the snap ros-foxy-ros-core has the slot:
ros-foxy-ros-core
the snap ros-foxy-ros-base has the slots:
ros-foxy-ros-core
ros-foxy-ros-base
the snap ros-foxy-desktop has the slot:
ros-foxy-ros-core
ros-foxy-ros-base
ros-foxy-desktop
And equivalently for humble & noetic variants.
Reciprocally, plugs would also have to adopt this more exhaustive naming schema of course.
This more meaningful naming addresses the concern of a (current) ros-foxy plug expecting the ‘desktop’ set to wrongly auto-connecting to a (current) ros-foxy slot only providing the ‘core’ set for instance.
@emitorino Any thoughts? Would that address the concern you raised?
@artivis thanks for the analysis. The proposal looks good for me, and if they work for the ros ecosystem, I think we can proceed with the declaration grant. Can other @reviewers please check this?
This is now live. Please let us know if you experience any issues.
I’m not sure what has been granted since I was in the middle of implementing the changes discussed in this thread. The content snaps have just been updated as per the description in my post. Did all snaps got auto-connect for all of their slots?
The associated change in snapcraft has just landed yesterday. I believe it has landed on edge already but should still take a few days to make it to stable. I was thus going to friendly ping this thread today but it seems you’ve beat me at the finish line :D.
hi @artivis, that is very good timing! I went through each of the snaps you mentioned in you post and then have granted global autoconnect on each of the slots you mentioned per snap.
e.g
ros-foxy-desktop has global autoconnect on the slots:
ros-foxy-ros-core
ros-foxy-ros-base
ros-foxy-desktop
ros-foxy-ros-base has global autoconnect on the slots:
ros-foxy-ros-core
ros-foxy-ros-base
etc, etc
Please let me know if that was not the intended adjustment or if there are any other issues and we can fix it up
@artivis since this seems to be working I am removing this request from our review queue. Feel free to write here if you have any further question! Thanks!
,
.