Treat exec_dependencies differently

[Spenser-Dewey]

Obviously, I recognize that for build order, the packages must still have a topological ordering for colcon to work and identify what to build when. But, there doesn't seem to be a reason why you couldn't make the distinction that build_depend/test_depend needs a consistent topological order, and exec_depend does not have that constraint. If one package requires another package to run, it just needs the package to be present in the environment by the time it runs, implying no build ordering.

This change is not only pedantic, it could also allow for better parallelization in building packages that are linked by exec_depend.

Unfortunately, the fact that there is no distinction between <test_depend>, <exec_depend>, and <build_depend> has caused me this particular issue:

In a plugin architecture I've been working with, one package (A) holds various important functions that the plugins need to call, and dynamically loads in and executes code from these plugin modules. These plugin modules use the API functions that A provides, and in this case extend some base class defined in A. Therefore, the plugin modules all have a build_depend to A. In an automated test in A, A loads in a well-defined plugin (B), and confirms that everything is working as expected with the architecture.

Now the problem is that when I want to run my usual automated tests on this package, I'd colcon build --packages-up-to A; colcon test, but that doesn't build B unless I've added a <test_depend>B<test_depend>, so the test fails. But I can't add that dependency without everything breaking, because B already has a <build_depend> on A.

Of course, there are plenty of ways around this: I could just build every package in my workspace for automated testing, or stop depending on --packages-up-to and manually specify, I could redesign the tests or potentially even split up the plugin library functions from the portion of code that dynamically loads plugins....
But I hate to change this existing project to force a topological order, when the natural solution is to simply declare it a '<exec_depend>' and have plugin B added to the set of packages to build! Really I want a <test_exec_depend>, but that's much less reasonable.

I wanted to post this here in case I'm overlooking something about the way <exec_depend> works, and to ask if this is the right place to update this. I could probably do something similar to what I want by using a PackageAugmentationExtensionPoint and add some custom tag to the package.xml to indicate a <unordered_depend> or something along those lines, and if you think that's a better approach than that's what I'll do. But it really seems to me that these <exec_depend> tag is perfect for this, especially after reading through https://www.ros.org/reps/rep-0149.html#exec-depend-multiple; it's already baked into the package format colcon is supporting.

Similar vein as #528 as far as colcon not seeming to differentiate between these different dependency types, or at least having no built-in way to interact with the different types of dependency.

[cottsay]

Hi there, thanks for your interest in this. I have lots of thoughts on how to improve colcon's dependency mechanics. It gets pretty complicated as you dig deeper. I'm pretty focused on some other work right now, but I'll try to circle back here down the road to discuss how we might move forward.