Prepare to release rosdoc2 into the ROS apt repositories.

[nuclearsandwich]

In order to make rosdoc2 easier to use locally, I'm preparing to release it via the ros_bootstrap repo into ROS repositories.

While building and running test installs of the package I found a few issues.

• Drop Ubuntu Bionic
• Add Ubuntu Jammy
• Add Ubuntu Noble
• Drop Debian Stretch
• Drop Debian Buster
• Add Debian Bookworm
• Add Debian Trixie
• Drop Ubuntu Focal (exhale and myst-parser are not available on Focal)

[rkent]

I don't know anything about ros_bootstrap, but let me make what comments I can.

• We've traditionally required graphviz as well as doxygen, but looking things over I don't know why. If it is not needed we should remove it from the test setups as well. I ran the tests without it and it seemed to pass.
• python3-osrf-pycommon is first available in mantic, so not available in jammy per here I don't know if this affects you or not.
• You did not change this, but do you really want python3-catkin-pkg-modules instead of python3-catkin-pkg?
• I would be happier if you added tests to demonstrate the success of stdeb.cfg in generating a debian install, independent of ros_bootstrap. If you think that is worthwhile but you don't want to do it, I could probably do it later myself.

[nuclearsandwich]

• We've traditionally required graphviz as well as doxygen, but looking things over I don't know why. If it is not needed we should remove it from the test setups as well. I ran the tests without it and it seemed to pass.

I don't either. Is it an indirect / optional dependency of doxygen perhaps?

• python3-osrf-pycommon is first available in mantic, so not available in jammy per here I don't know if this affects you or not.

Open Robotics doesn't rely on the upstream versions of our software. Instead, packages like bloom and catkin-pkg are released to a repository called ros_bootstrap, which isn't intended for ROS users but is used to for packages that are imported to the ROS repositories but are not built on the ROS build farm where we also publish our own deb version of osrf_pycommon. The generated deb is not expected to be installable on systems where the ROS repository is not configured and so may depend on packages only available in that repository.

• You did not change this, but do you really want python3-catkin-pkg-modules instead of python3-catkin-pkg?

Yes, in the osrf-packaged projects which support both python2 and python3. The packages are separated so that you can install the python modules in both versions but only have one package provide the scripts. https://github.com/ros-infrastructure/catkin_pkg/blob/03bc290d2ccf66dce2fa84632ac611b71bfa8f74/setup.py#L66-L72
Without a change like that, you would have to uninstall python-catkin-pkg in order to install rosdoc2. If however, rosdoc2 actually depends on one of the scripts installed by catkin_pkg, such as catkin_generate_changelog, then we would need to declare the deb dependency on python3-catkin-pkg and we would be incompatible with python-catkin-pkg.

• I would be happier if you added tests to demonstrate the success of stdeb.cfg in generating a debian install, independent of ros_bootstrap. If you think that is worthwhile but you don't want to do it, I could probably do it later myself.

Thanks for the offer! Infra projects use https://github.com/ros-infrastructure/ros_release_python to automate deployment of infra packages to the ros_bootstrap repository and pypi. What I'd like to do is provide a GitHub Action that can be used in any of our projects to run that script and report success or failure. I think that's worth doing rather than having independent actions implementations in each project. I might take a stab at that and will tag you for review on adding it to rosdoc2.

[clalancette]

• We've traditionally required graphviz as well as doxygen, but looking things over I don't know why. If it is not needed we should remove it from the test setups as well. I ran the tests without it and it seemed to pass.

I don't either. Is it an indirect / optional dependency of doxygen perhaps?

So I believe it is to support dot functionality directly in Sphinx. If you look at e.g. https://github.com/ros2/ros2_documentation/blob/53783dcb77a0451a190a4d0372afc28c685127fd/source/Concepts/Intermediate/About-Executors.rst#L67-L79 , that ends up generating http://docs.ros.org/en/rolling/Concepts/Intermediate/About-Executors.html#types-of-executors . I think we wanted the same functionality to be available to rosdoc2 users, which is why it is currently a dependency.

That said, I have no idea if any packages are actively making use of this functionality.

[nuclearsandwich]

So I believe it is to support dot functionality directly in Sphinx. If you look at e.g. https://github.com/ros2/ros2_documentation/blob/53783dcb77a0451a190a4d0372afc28c685127fd/source/Concepts/Intermediate/About-Executors.rst#L67-L79 , that ends up generating http://docs.ros.org/en/rolling/Concepts/Intermediate/About-Executors.html#types-of-executors . I think we wanted the same functionality to be available to rosdoc2 users, which is why it is currently a dependency.

Thanks for that pointer! The build engineer in me would most like to keep graphviz (and even myst-parser) out of the tool's required dependencies and have packages which use those specify explicit doc_depend keys. Then handle their absense in rosdoc2 when used without it. But I am alright kicking that can down the road in order to get an initial release out. @rkent how does that sound to you?

For reference Markdown support was added unconditionally in #21 so that ship may have long since sailed.