Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automation tooling for upkeep of package.xml #12

Open
jwnimmer-tri opened this issue Mar 10, 2024 · 2 comments
Open

Automation tooling for upkeep of package.xml #12

jwnimmer-tri opened this issue Mar 10, 2024 · 2 comments

Comments

@jwnimmer-tri
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants