-
Notifications
You must be signed in to change notification settings - Fork 24
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
omnibus-2024-08-02 #557
omnibus-2024-08-02 #557
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just some minor suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally got through everything, LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Synopsis
Simplify access to drivers' internal config. Previously, we had
.config
,.config_full
, and._driver_config
properties..config
provided the block including the driver's own block and theplatform
block (i.e.{"driver-name": ..., "platform": ...}
);.config_full
provided the full input config, even content not relevant to the driver;._driver_config
provided the block underdriver-name
. This PR simplifies this: The private instance variable._config_full
now provides the{"driver-name": ..., "platform": ...}
block, and.config_full
provides a public read-only copy of that; and the private instance variable._config
now provides the block underdriver-name
, and.config
provides a public read-only copy of that. So,.config
replaces the old._driver_config
, and.config_full
replaces the old.config
. The driver no longer retains a copy of the complete input config, discarding the irrelevant parts of that input. Many references to these properties are updated to make use of this simpler arrangement.Update
uwtools.api.driver
to explicitly import theAssets
andDriver
class families, instead of dynamically adding these to the module. I found in starting external coupled-driver development that runningpylint
on that driver code flagged e.g.from uwtools.api.driver import DriverCycleBased
, reporting thatuwtools.api.driver
has noDriverCycleBased
member. From a static analysis perspective, this is true: The class is added to the module only when it is imported and its top-level code executed, sopylint
cannot know this. Without this change, all external driver developers would have to suppress complaints from static analyzers likepylint
.Refactor the key-path walking and error-checking code to a public function, and call it from the
Assets
constructor so that key-path walking there benefits from error checking and reporting.Add public
.cycle
and.leadtime
properties on the appropriate driver classes. I see no reason to hide these, and where external drivers need to access these values, using e.g.self.cycle
is IMO less surprising thanself._cycle
.Remove some
.mkdir()
calls where they are no longer necessary when they rely on downstream code that already makes necessary parent directories.I recently realized that
Path()
accepts multiple arguments, similar to the legacyos.path.join
, so I've simplified some calls likePath(a) / b
toPath(a, b)
. It's only one character shorter, but IMO looks simpler and more familiar.Fix some API docs.
See some inline comments, too.
Type
Impact
Checklist