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.
As part of PR #6 currently, @j-rivero has manually transcribed the dependency
*.txtfiles from drake/setup/ubuntu into this repository'spackage.xmlfile, 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
mainthat 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
*.txtfiles and rewrite thepackage.xmlmanifest 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.xmlfile 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.