Add package.xml

[azeey]

🎉 New feature

Summary

Add package.xml based on dependencies found in .github/ci/packages.

This is to test out using vendor packages to provide Gazebo packages to ROS users (see gazebo-tooling/release-tools#1117).

Test it

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[scpeters]

are package.xml files typically installed?

[scpeters]

I think we should have a plan for how to keep this version tag in sync with the version in the CMakeLists.txt.

Some options:

1. Manually update version numbers in both places and add a CI check to verify consistency (presumably with a shared github action that we will use in other packages)
2. Make this package.xml version string the single source of truth and add cmake logic to parse the package.xml file to get it (presumably using the existing code that ROS / ament is already using)

I won't block this pull request on that change, but I'd like to at least have an issue open where we continue this conversation

[scpeters]

I think option 1 would be easier to implement

[scpeters]

add cmake logic to parse the package.xml file to get it (presumably using the existing code that ROS / ament is already using)

I believe the following ament_cmake macro is used to invoke the ament_package python scripts:

• https://github.com/ament/ament_cmake/blob/9743c9cd3e5aef9566acefea6e6e3724e0e5657e/ament_cmake_core/cmake/core/ament_package_xml.cmake
• https://github.com/ament/ament_package

[scpeters]

I just hacked up a crude github workflow check for consistent versions in the CMakeLists.txt and package.xml file in branch package_xml...package_xml_ci_test

@j-rivero where would you like to see this CI configuration stored?

[azeey]

I should have mentioned I've added a workflow in some of the other package.xml PRs. See https://github.com/gazebosim/gz-sim/actions/runs/8334724361

[azeey]

I've added an Action in gazebo-tooling/action-gz-ci#70 and updated this PR to use it.

[scpeters]

are package.xml files typically installed?

for ROS packages, it looks like the package.xml files are installed to {install_prefix}/share/{package_name}/package.xml

[azeey]

are package.xml files typically installed?

for ROS packages, it looks like the package.xml files are installed to {install_prefix}/share/{package_name}/package.xml

For the purposes of creating the ROS vendor packages, I don't think we need to install package.xml. In general, I was hoping to avoid any changes to our CMake code to support the package.xml file and instead treat it as a convenient place to put our dependencies (so we can use rosdep) and also as the source of truth for generating/updating vendor packages with automated tools.

[scpeters]

For the purposes of creating the ROS vendor packages, I don't think we need to install package.xml. In general, I was hoping to avoid any changes to our CMake code to support the package.xml file and instead treat it as a convenient place to put our dependencies (so we can use rosdep) and also as the source of truth for generating/updating vendor packages with automated tools.

sounds good

[azeey]

gazebo-tooling/action-gz-ci#70 adds validation of the package.xml using ament_xmllint and it seems like dashes (-) are not allowed in <name> tags 😱. Should we switch to underscores for just the package.xml?

[scpeters]

gazebo-tooling/action-gz-ci#70 adds validation of the package.xml using ament_xmllint and it seems like dashes (-) are not allowed in <name> tags 😱. Should we switch to underscores for just the package.xml?

from https://ros.org/reps/rep-0149.html#name

The package name must start with a letter and contain only lowercase alphabetic, numeric or underscore characters

but also

The following recommended exemptions apply, which are optional for implementations:

• Dashes may be permitted in package names. This is to support maintaining a consistent dependency name when transitioning back and forth between a system dependency and in-workspace package, since many rosdep keys contain dashes (inherited from the Debian/Ubuntu name).

so maybe ignore that specific linter complaint?

[azeey]

gazebo-tooling/action-gz-ci#70 adds validation of the package.xml using ament_xmllint and it seems like dashes (-) are not allowed in <name> tags 😱. Should we switch to underscores for just the package.xml?

from https://ros.org/reps/rep-0149.html#name

The package name must start with a letter and contain only lowercase alphabetic, numeric or underscore characters

but also

The following recommended exemptions apply, which are optional for implementations:

• Dashes may be permitted in package names. This is to support maintaining a consistent dependency name when transitioning back and forth between a system dependency and in-workspace package, since many rosdep keys contain dashes (inherited from the Debian/Ubuntu name).

so maybe ignore that specific linter complaint?

This was discussed at today's ROS 2 meeting. The conclusion was that the REP is the authority here. The plan is to relax the naming requirement in the .xsd and potentially provide an opt-in linter that warns against use of dashes. See ros-infrastructure/rep#400.

In the meantime, we can comment out the ament_xml_lint from our CI and merge this.