datalad / datalad-extension-template

Minimal implementation of a DataLad extension module
http://datalad.org
Other
2 stars 17 forks source link

Extension logging without instructions #39

Open mih opened 2 years ago

mih commented 2 years ago

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.

yarikoptic commented 2 years ago

In https://github.com/datalad/datalad-extension-template/issues/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