Skip to content
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

Extension logging without instructions #39

Open
mih opened this issue Jun 1, 2022 · 1 comment
Open

Extension logging without instructions #39

mih opened this issue Jun 1, 2022 · 1 comment

Comments

@mih
Copy link
Member

mih commented Jun 1, 2022

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
Copy link
Member

yarikoptic commented Jun 1, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants