search

RobotLocomotion / ros-drake-vendor

Maintainer scripts that package Drake in the ROS build farm
Other
1 stars 1 forks source link

Automation tooling for upkeep of package.xml #12

Open jwnimmer-tri opened 3 months ago

jwnimmer-tri commented 3 months ago

As part of PR #6 currently, @j-rivero has manually transcribed the dependency *.txt files from drake/setup/ubuntu into this repository's package.xml file, to match the currently-pinned version of Drake.

This is a fine way to bootstrap the work (and it's no problem to merge it to main that way), but for ongoing maintenance it is too costly & risky to keep doing that by hand. Before we finish this project, we'll need some kind of automation tooling that makes it easier (and safer) to upkeep the dependencies when switching to a newer pin of Drake, so that any Drake developer can perform the upkeep on a regular basis.

That could be a program that fully automates the process -- given the new version of Drake, it would read the *.txt files and rewrite the package.xml manifest with the new content. I'm not sure that the effort involved in writing a fully-automated tool would be worth it, though.

Instead, I imagine a better use of our time would be to write a tool that cross-checks the two lists, i.e., a linter. It would load both sets of data (the xml list, and the txt lists) and identify any dependencies that exist in one list but not the other, or are mis-categorized between build-time vs run-time dependencies. It could have some hard-coded list of special cases or heuristics, to help smooth over any differences. It would be run as a CI job, as a reminder for any pull requests to adjust what's necessary. The developer would still need to act on the report, either by editing the package.xml file or adjusting the heuristics.

In any case, that's just one idea. The bottom line is that we need the "upgrade drake version" process to be runnable by Drake developers, without needing any special skills.

jwnimmer-tri commented 3 months ago

I'll also toss it in here since it's probably part of the same overall solution (tool and/or documentation) ...

We'll also need a CI lint check that the <version>1.26.0</version> in package.xml and the VCS_VERSION v1.26.0 in CMakeLists.txt are in sync. (Or alternatively, a tool that automatically changes both at the same time, in which case perhaps no linter is needed.)

j-rivero commented 3 months ago

We'll also need a CI lint check that the <version>1.26.0</version> in package.xml and the VCS_VERSION v1.26.0 in CMakeLists.txt are in sync. (Or alternatively, a tool that automatically changes both at the same time, in which case perhaps no linter is needed.)

I think that we can get rid of this one with #15