Consider ignoring setup.py if there is no package.xml at that level?

[sea-bass]

I was running into an issue trying to build only the ROS part of a third-party package that looks something like this.

bindings/
cpp/
  include/
  src/
  CMakeLists.txt
  package.xml
python/
setup.py

So what happens is when I run colcon build, I want it to just build that cpp folder.

However, the setup.py is also picked up, and in this case is not desired. I also can't put a COLCON_IGNORE there because it would include the folder I do want to build.

Would it make sense to ignore that setup.py if there is no package.xml at that level? Or am I missing something (very likely)?

[mikepurvis]

The design intent is that colcon can discover and build packages with non-package.xml metadata. Indeed, this capability is one of colcon's tentpole features over catkin_tools, which is completely dependent on package.xml files for package discovery.

There are various mechanisms you can use to have colcon to ignore a path or package— a COLCON_IGNORE file, the --packages-ignore or --package-skip flags, the --paths flag, probably something with colcon-metas, maybe others I'm not thinking of.

[sea-bass]

Got it, thank you!

I think the best bet then is to rearrange the repo file structure so that I can place a COLCON_IGNORE in the right place.

[cottsay]

This isn't the first time I've heard of someone trying to do something like this. I don't know if there are any perfectly fit features to handle it right now. There is crossover into some discussions happening in colcon-cargo around the support for Cargo workspaces.

I'd like to look at using the colcon.pkg files as a way to signal that there is actually not a package in the current directory. It looks like setting the package type to null doesn't currently do anything, so we might be able to use that as a way to say that there isn't a package here. Or maybe a placeholder value.

This is really meant to be a signal to colcon-recursive-crawl so that it continues to traverse into the package's directory. This can be dangerous if not done intentionally - we have lots of examples of things that look like packages checked in as test resources. It will have to be specifically opt-in behavior.