I'm working on a new snapcraft plugin for colcon (using crystal) and I've hit a bit of an issue. The way ROS snaps are built today ends up installing all packages into the same workspace, which if you ignore snaps ends up being the system workspace in /opt/ros/<rosdistro>/. This works fine with Catkin, just source /opt/ros/<rosdistro>/setup.sh, and run catkin_make_isolated --install --install-space /opt/ros/<rosdistro>. This worked because the setup.sh was the same. However, I'm trying to accomplish the same thing with Colcon and it's proving troublesome. The setup.sh and local_setup.sh is customized for the given workspace, and the one in /opt/ros/<rosdistro> is far different, and overwriting the system one with the workspace's of course doesn't work. It looks like things work with colcon build --merge-install as long as I don't install the setup.sh and local_setup.sh generated for the workspace (and instead rely on the package-level ones), although I haven't pushed that path too hard. Is there a way to request that these files aren't generated/installed? Looking through the code I thought maybe AMENT_CMAKE_ENVIRONMENT_GENERATION was what I was looking for, but it seems to have no effect on those files. Am I missing something?

Update 1 To answer some questions asked in answers:

So I assume multiple snaps installing the same file (as long as it is identical) is ok? (I am just asking because e.g. for Debian packages that is not the case.)

Yes and no. In the typical case that I'm talking about here, snaps are isolated such that if one were to install multiple ROS snaps, they install alongside each other, not on top. They end up being independent workspaces that don't know the other exists. What I'm talking about in this question is installing multiple ROS packages in a single workspace into the same snap (along with, say, ros-crystal-ros-base). In this case, any clashing file ends up being overwritten by the installation of the workspace into the snap where ros-crystal-ros-base is already located, which is why I tried to compare it to just installing with root privs on the system into the root workspace used by the OR-provided debs. It's essentially the same, it's just not garbaging up the system's ROS install at that point.

Can you please describe how they are different and if you are referring to the ones generated by colcon or by ament_cmake? (A comment line at the top of the files should clarify which template they have been expanded from.)

This may be the crux of the issue. The version installed by the OR debs is from ament, the version installed in the workspace is from colcon (this statement applies to both setup.sh and local_setup.sh). I can't pretend to be an expert here, but they don't seem compatible in that the colcon setup.sh just sources the local_setup.sh which runs _local_setup_util.py which only discovers colcon packages in <prefix>/share/colcon-core/packages/, which at least in my simple talker/listener test with ros-crystal-ros-base installed ONLY includes my talker and listener, none of the OR ROS components.

Update 2:

Ok, as far as I understand you are using two workspaces: * the underlay in /opt/ros/crystal provided by Debian packages * the overlay (in the form of a snap) somewhere else which is supposed to depend on the underlay (so it was built with colcon and the underlay being sourced before)

And the problem is that when sourcing the setup.sh from the overlay workspace that you don't get anything from the underlay. Right?

Mostly correct. The underlay is actually already IN the snap (not on the system, I was using that for comparison), and I'm trying to install the overlay into the snap as well. There are two ways to do that: install the overlay into another directory and keep it as a separate workspace and chain them in production, or install the overlay directory INTO the underlay so that in production there is only one workspace. The latter is the path we took for Catkin, and I'm attempting to do the same for Colcon. How are you handling this in the Debian packaging of Colcon components to work alongside the Ament ones?

Regarding the effect, I was about to say you were spot on, but then it started working for me like magic. I must have broken this on my own, which is pretty embarrassing, I'm sorry. However, the fact that it wasn't working made perfect sense-- these setup scripts are quite different. How is this working?

Update 3:

Ah ha, I found what I did. It was switching from a normal install to a merge install where it started finally working (teach me to change too many things at once). This still feels a bit dirty though, and I'd be surprised if it worked for everything.