Repository navigation
Unify naming conventions for analysis/planning outcome messages. #23
Description
There are a few cases I've run into where the naming conventions of things in analyzers and planners seem to clash.
- Analyzer services takes an
AnalysisRequestobject and return anAnalysisobject while Planner services take aPlanRequestand return aPlanResponseobject. We should either changeAnalysistoAnalysisResponseorPlanResponsetoPlanmake everything line up. - The
Analysisobject uses the fieldoutcomefor ARES outcome/status messages, whilePlanResponsehas the fieldplanning_outcome. We should probably just make these bothoutcome.
The question now is how can we do this without breaking previous code, or at least adding in a depreciation message.
Activity
nkleiner commentedon Jun 10, 2026
I think this is a scenario in which we can make some changes that are "breaking" in nature. For the purposes of addressing this comment, we only need to make changes to the PyAres library. Eventually I might have a burning desire to make these changes be reflected more directly in the data model, but ultimately they're simply to keep our naming a bit more consistent which is much more important to the average user than it is to the developers who have built the architecture. So what we can do is simply change the naming of these two items in the python library itself, which will give any PyAres users that consistent naming you're looking for.
Making this change directly in the code as a replacement WILL break scripts that update to the newest PyAres, but given this will be a PyAres change only they will continue to function on both the current and future version of ARES. Not to say people will never update PyAres, but they won't be prompted to unlike with ARES itself. And if they do update their PyAres version, their changes will be so minimal that I'm not sure it's worth blocking the swap for. Open to additional thoughts
arthursloan commentedon Jun 11, 2026
Right now think I'm the one with the most PyAres modules, so I'd be the most impacted by a breaking change. I'd say its better to do this now before the external user base gets to big so if you don't have an issue with just making the change I'm in favor of going for it.
nkleiner commentedon Jun 11, 2026
I've gone ahead and made the changes we talked about and linked the pull request. If you feel comfortable doing so feel free to check out the changes and provide comments as you'd like @arthursloan otherwise I'll likely just merge this in sometime tomorrow afternoon.
arthursloan commentedon Jun 11, 2026
Looked over the changes. It all looks good to me!
nkleiner commentedon Jun 17, 2026
These changes got merged in alongside a bunch of others in pull request #26 and will be part of the next release of PyAres