You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, extensions mostly use a logger name that starts with datalad. in order to get a logger that behaves like the ones from datalad-core. However, this requires them to "fake" some kind of namespace location underneath datalad...., which may or may not conflict now or in the future with an actual component of datalad core.
It seems better to make this explicit.
With the help of @bpoldrack I was able to determine that the following line from datalad/log.py might be the key to this.
lgr=LoggerHelper().get_initialized_logger()
LoggerHelper can actually receive a name argument, which defaults to datalad. So this could be changed to an extension namespace, e.,g. datalad_osf.
However, in order to make this possible, it requires fixes to that class first. While the name is treated as variable, it is also used as the configuration item prefix. So the logger would start querying from config items: datalad_osf.log.level instead of datalad.log.level.
The text was updated successfully, but these errors were encountered:
In #27 I excercised an idea for datalad.ext. logging namespace, so it would become datalad.ext.datalad_osf (edit: or we could make it datalad.ext.osf, thus stripping duplicate datalad_ prefix present in extensions) prefix. I believe (without thorough analysis yet) it is advantageous to have datalad. prefix to ensure harmonious logging between datalad and its extensions. If extensions would have their own prefix, e.g. datalad_osf, then I believe control of their logging behavior might then diverge/require their own settings etc. I could be proven wrong
Right now, extensions mostly use a logger name that starts with
datalad.
in order to get a logger that behaves like the ones from datalad-core. However, this requires them to "fake" some kind of namespace location underneathdatalad....
, which may or may not conflict now or in the future with an actual component of datalad core.It seems better to make this explicit.
With the help of @bpoldrack I was able to determine that the following line from
datalad/log.py
might be the key to this.LoggerHelper
can actually receive aname
argument, which defaults todatalad
. So this could be changed to an extension namespace, e.,g.datalad_osf
.However, in order to make this possible, it requires fixes to that class first. While the name is treated as variable, it is also used as the configuration item prefix. So the logger would start querying from config items:
datalad_osf.log.level
instead ofdatalad.log.level
.The text was updated successfully, but these errors were encountered: