I am seeking approval for tesseract-ignition setup wizard to use the interface system-files. This is a ROS developers tool that supports the creation of a semantic robot description file. ROS is typically installed in the /opt/ros directory which requires the use of the system-files interface to expose this directory on the hosts machine. The interface is only used to read information from this location and is not setup to write to this location. This was determined through this discussion.
As I mentioned in the other thread, tesseract presents the user with a list of discovered 3D meshes which can be imported. Some of these meshes are shipped in tesseract itself, but the user can also have their own installed, in which case they will most likely be contained in /opt/ros on the host or in the user’s home directory (the latter of which is covered by the existing home interface).
To be clear, tesseract does not own /opt/ros. That said, no single thing really does, that’s just where ROS workspaces are conventionally installed (e.g. all upstream ROS components gets installed there). One could say it’s owned by ROS, but ROS is just a collection of software (that includes tesseract) much like Ubuntu is a collection of software.
In many cases for a ROS snap, the snap is self-sufficient and it doesn’t make sense for it to care if ROS is installed on the host. Even if it did, if it tried to load a library from there it would probably fail as it wouldn’t be able to link to other libs. In this case, however, this snap is a utility that operates on a given ROS workspace and only loads meshes out of it. As a result, granting it access to the default ROS workspace on the host seems useful and reasonable to me, but I provide this background to make it clear that the precedent we’re setting is narrow.
I’m +1 to granting access to the following interface (though I’m flexible on the name, @jdstrand will have more thoughts):
@Levi-Armstrong you did not request that this interface be automatically connected upon install. I’m pointing this out in case you wanted it that way. If so, my initial thought is that having access to the host-installed ROS workspace doesn’t seem to be a core, required feature (i.e. tesseract still seems useful without it), but that’s not a tremendously informed opinion and I’d like your thoughts on it.
You are correct that it is useful without it. If all resources are in the home directory then you don’t need the interface, but in almost every case they will likely be using some resource from the /opt/ros. Example the parent urdf may be in home directory but it usually references a robot model in the /opt/ros location. I not sure what the best practice is here, but I vote for the auto connect because in most cases it may be used. What are your thoughts?
+1 for read-only access to /var/lib/snapd/hostfs/opt/ros for this snap, but please adjust to use this for the interface reference since it aligns with other patterns:
2 votes for, 0 against for use of and auto-connection for system-files to /var/lib/snapd/hostfs/opt/ros using the interface reference of hostfs-opt-ros. Granting. This is now live.
@Levi-Armstrong - there is a corresponding change to the review-tools that must be made that is not yet in production, so your snap will need to be manually approved until it is. I’ve done that for revision 9 already.
If I understand correctly, every time I push changes it will require a manual review? Should I make the request here or will you be notified when I push changes? Over the next few weeks I plan to add new features to the GUI but the snapcraft.yaml should not change so I will do my best to limit the number of pushes.
Only until the review-tools change is in production, after that, it will pass automated review. Feel free to upload like normal and reviewers who monitor the queue will manually approve it.
