REP 149: No way to mark dependencies as optional

[rotu]

It would be nice to add some flexibility in dependencies. While package.xml is used for sequencing builds, it's currently unsuitable for generating a list of concrete package dependencies since some packages are optional.

@dirk-thomas

Please feel free to describe how colcon should determine that based on the available information from the package manifests.

...

Group dependencies are not necessarily optional. There are cases where you e.g. need at least one of package from the group in order to work properly. That semantic isn't encoded in the manifest because the community wasn't able to reach a consensus when this was proposed (I don't have a link to that discussion at hand).
Therefore I don't think an option to just ignore group dependencies is sufficient.

Originally posted by @dirk-thomas in ros2/rmw_dds_common#16 (comment)

[rotu]

It may make sense to do this via adding an optional attribute to dependency tags or grouping some dependencies under named dependency sets like python setuptools extras https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies

[dirk-thomas]

In order to be able to move forward on this idea someone needs to come up with a more detailed proposal. That needs to include the exact changes to the manifest as well as how the additional metadata is being used by the various tools (e.g. bloom, rosdep, colcon).

[rotu]

Indeed. Though even if the tooling does not yet support it, this info is useful for human consumption (like the specified but ignored <doc_depend> tag)

[dirk-thomas]

Though even if the tooling does not yet support it, this info is useful for human consumption

Please see other REPs on this topic. Neither of them has been ratified until their semantic was clearly defined as well as all affected tools touched.

like the specified but ignored <doc_depend> tag

This tag is not ignored but being used by e.g. the doc jobs on the buildfarm.

[rotu]

Please see other REPs on this topic. Neither of them has been ratified until their semantic was clearly defined as well as all affected tools touched.

The semantics sure, but not so much the tooling implementation details. For instance, the description for test_depend states that it's for a package needed for testing, but AFAICT, nowhere does it prescribe whether or when rosdep should install those packages, and the REPs omit mention of colcon entirely.

This tag is not ignored but being used by e.g. the doc jobs on the buildfarm.

I figured the buildsystem is basically "the software running on the buildfarm", but now I have no idea what this means. At any rate, the future tense led me to wrongly believe it's not yet used:

The current version of the buildsystem does not provide any documentation specific functionality or targets but may do so in the future, similar to how the unit tests are integrated into the configure and make steps. Other infrastructure (like the documentation jobs on the buildfarm) will utilize these additional doc dependencies.