ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

You could see whether using symlinks to get package_from_github_A up to catkin_ws/src level, but tbh I would not recommend you do that.

Nesting packages like this is expressly not supported. Not in ROS 1, nor in ROS 2.

(I'm guessing the nested structure comes from using git sub modules?)

You could see whether using symlinks to get package_from_github_A up to catkin_ws/src level, but tbh I would not recommend you do that.

Nesting packages like this is expressly not supported. Not in ROS 1, nor in ROS 2.2 (or to be more precise: not by Catkin, nor Colcon/Ament).

(I'm guessing the nested structure comes from using git sub modules?)

You could see whether using symlinks to get package_from_github_A up to catkin_ws/src level, but tbh I would not recommend you do that.

Nesting packages like this is expressly not supported. Not in ROS 1, nor in ROS 2 (or to be more precise: not by Catkin, nor Colcon/Ament).

From #q319867:

A ROS package is defined as a directory with a package.xml file. Similar to how a CMake package (CMakeLists.txt) and Python package (setup.py) file is defined. Everything recursively under that directory is part of that package. As a consequence packages can't be nested.

Another related Q&A: #q259586.

(I'm guessing the nested structure comes from using git sub modules?)

You could see whether using symlinks to get package_from_github_A up to catkin_ws/src level, but tbh I would not recommend you do that.

Nesting packages like this is expressly not supported. Not in ROS 1, nor in ROS 2 (or to be more precise: not by Catkin, nor Colcon/Ament).

From #q319867:

A ROS package is defined as a directory with a package.xml file. Similar to how a CMake package (CMakeLists.txt) and Python package (setup.py) file is defined. Everything recursively under that directory is part of that package. As a consequence packages can't be nested.

Another related Q&A: #q259586.

(I'm I'm guessing the nested structure comes from using git sub modules?)

modules?


Edit:

Yes, these are submodules. My idea is to make it easy to download our source code by having the necessary includes as nested within the package. I’m guessing the standard way to structure these packages is to keep all root package folders just below src?

That would be one option.

More commonly people use something like vcstool to populate their workspace.

See also #q347421 and the linked Q&As in the accepted answer there.

Creating, populating and building a ROS workspace can be done in about 4 to 5 commands. That's a very good compromise which gets you a lot of flexibility without encoding the structure of your workspace in a VCS.

You could see whether using symlinks to get package_from_github_A up to catkin_ws/src level, but tbh I would not recommend you do that.

Nesting packages like this is expressly not supported. Not in ROS 1, nor in ROS 2 (or to be more precise: not by Catkin, nor Colcon/Ament).

From #q319867:

A ROS package is defined as a directory with a package.xml file. Similar to how a CMake package (CMakeLists.txt) and Python package (setup.py) file is defined. Everything recursively under that directory is part of that package. As a consequence packages can't be nested.

Another related Q&A: #q259586.

I'm guessing the nested structure comes from using git sub modules?


Edit:

Yes, these are submodules. My idea is to make it easy to download our source code by having the necessary includes as nested within the package. I’m guessing the standard way to structure these packages is to keep all root package folders just below src?

That would be one option.

More commonly people use something like vcstool to populate their workspace.

See also #q347421 and the linked Q&As in the accepted answer there.

Creating, populating and building a ROS workspace can be done in about 4 to 5 commands. That's a very good compromise which gets you a lot of flexibility without encoding the structure of your workspace in a VCS.