Source control, packages, and metapackages in 2021?

edit

I have a couple of long threads in the details below, but I'd like your recommendations.

I don't see anything else after this line?

This strategy doesn't seem to need vcs or rosinstall which add extra mental overhead compared to "Clone the organization ROS monorepo into your Catkin workspace, run rosdep, and run catkin_make"

I realise every additional command is one additional command, but you're referring to:

mkdir -p /path/to/your/catkin_ws/src
git clone https://...
git clone https://...
[etc]
rosdep update && rosdep install --from-paths /path/to/your/catkin_ws/src -i ...
catkin build --workspace /path/to/your/catkin_ws

vs

mkdir -p /path/to/your/catkin_ws/src
vcs import /path/to/your/catkin_ws/src --input https://.../my_repos.repos
rosdep update && rosdep install --from-paths /path/to/your/catkin_ws/src -i ...
catkin build --workspace /path/to/your/catkin_ws

?

For any project with more than a single repository (which I believe is very likely to be the case), the vcs variant seems preferable to me.

About metapackages: #q256493.

Note: they do not wrap anything (physically). Packages cannot be nested.

They're convenience collections, like the Debian metapackage concept (ie: a single package makes apt install N other packages).

None of the source and/or repository management tools I know of care about metapackages, so they only seem to really make sense in case you plan to build binary packages (ROS buildfarm, an internal one or a more manual process) and distribute them in a format some platform package manager can consume.

Edit: well, maybe you could consider a .repos file some sort of metapackage, as it has a similar role, but then for source distributions. Metapackages can depend on other metapackages though, which allows for recursive management of dependencies. .repos files cannot.

Note: they do not wrap anything (physically). Packages cannot be nested.

This is a key thing that I was missing and figured out shortly after I posted my question. The fact that catkin (or/also CMake) doesn't care about arbitrarily nested directory structures was kind of lost on me, but then I realized that the metapackage is the universal_robot folder at https://github.com/ros-industrial/universal_robot, not the whole repository.

So on my disk, the metapackage is

src\universal_robot\universal_robot

The top-level universal_robot folder in src that was retrieved by

git clone https://github.com/ros-industrial/universal_robot.git

Does not have to be arranged that way. It's arbitrary and catkin doesn't care at all about it.

In the typical ROS convention (at least following tutorial folder structures), the metapackage would just be another folder in catkin_ws\src alongside all my other packages.

None of the source and/or repository management tools I know of care about metapackages, so they only seem to really make sense in case you plan to build binary packages (ROS buildfarm, an internal one or a more manual process) and distribute them in a format some platform package manager can consume.

Understood.

Edit: well, maybe you could consider a .repos file some sort of metapackage, as it has a similar role, but then for source distributions. Metapackages can depend on other metapackages though, which allows for recursive management of dependencies. .repos files cannot.

I think the .repos file may be what I need but now I think I actually understand how to get started concretely, which was not yet clear. Makes sense that the metapackage could be useful for dependency management.

I don't see anything else after this line?

Yeah there's nothing else, I forgot to edit out "below." I was referring to the Autoware and MoveIt discussions I linked above that line.