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
DM-6999: Logging framework migration #19
Conversation
15fba26
to
c649ca9
Compare
if log is None: | ||
log = pexLog.getDefaultLog() | ||
self.log = pexLog.Log(log, self._fullName) | ||
if log is not None and isinstance(log, Log): |
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.
Why is the isinstance
test? This was not present before and I'm very uncomfortable having it now. Is this a way of trying to avoid pex_logging? If so, is the problem serious enough to need avoiding? If so, please warn or raise if the wrong type of log is passed in. I am uncomfortable with code that silently ignores issues, as it leads to mysterious and silent failures.
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.
isinstance
is not needed here and we can just remove the check. What you said makes more sense; even if the check stays it should warn or raise if the wrong type of log is passed in.
08dac8a
to
12ab37a
Compare
@@ -127,7 +127,7 @@ def __init__(self, config=None, name=None, parentTask=None, log=None): | |||
config = self.ConfigClass() | |||
self._taskDict = dict() | |||
loggerName = self._fullName | |||
if log is not None: | |||
if log is not None and log.getName(): |
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.
Good that this is fixed! This was causing a fairly obtuse error!
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.
getName()
can return an empty string?
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.
Apparently yes. Try building pipe_base without this commit - testCmdLineTask fails with a fairly unhelpful error message.
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.
Yes, an empty string for the root logger.
Maybe we should improve the error message when we ask for a logger that doesn't make sense...
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.
Sure, I think that's a good idea.
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.
DM-7479 is added.
Setting the log destination from a string will not be supported by the log package. So instead of printing an error message that implies --logdest will eventually be supported again, I simply removed it.
With this transition, arbitrary integers are no longer accepted as levels. Six formal levels are used: TRACE < DEBUG < INFO < WARN < ERROR < FATAL Default format and logging level are set to be similar to how it was. Logging calls at pex.logging DEBUG level is replaced by lsst.log DEBUG level.
Include showing timestamp and data IDs (stored as LABEL)
If a root logger (with an empty name) is passed to Task's ctor, there should not be an extra "." added to the Task's log name.
fa2c220
to
d509100
Compare
No description provided.