Only call logging.basicConfig() when used as a command

[jwodder]

Closes #466.

[codecov]

Codecov Report

Merging #468 (6fd5f0c) into master (8522a13) will decrease coverage by 0.07%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #468      +/-   ##
==========================================
- Coverage   82.22%   82.15%   -0.08%     
==========================================
  Files          55       55              
  Lines        5750     5749       -1     
==========================================
- Hits         4728     4723       -5     
- Misses       1022     1026       +4     

Flag	Coverage Δ
unittests	82.15% <0.00%> (-0.08%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
dandi/__init__.py	70.00% <ø> (-2.73%)	⬇️
dandi/cli/command.py	44.59% <0.00%> (-0.62%)	⬇️
dandi/support/pyout.py	77.21% <0.00%> (-3.80%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8522a13...6fd5f0c. Read the comment docs.

[yarikoptic]

but what will happen if used as a Python module - every script would need to setup logging for our logger and thus we would loose ability to quickly enable logging via DANDI_LOG_LEVEL env var?

[jwodder]

@yarikoptic DANDI_LOG_LEVEL still takes effect via the line in dandi/__init__.py, and if a user's script calls basicConfig(), then the logging level will be preserved, and dandi's logs will be sent to stderr. Is that good enough, or do you want the dandi logger to always have a StreamHandler attached so that it always writes to stderr even without the user configuring anything?

[yarikoptic]

Is that good enough, or do you want the dandi logger to always have a StreamHandler attached so that it always writes to stderr even without the user configuring anything?

that is what I thought but I wonder if that is generally a good strategy for a Python module? I did see double logging when datalad is used as a module and I wonder if that was a reason and should generally be avoided

[jwodder]

@yarikoptic The official Python logging tutorial has this to say about logging in a library:

It is strongly advised that you do not add any handlers other than NullHandler to your library’s loggers. This is because the configuration of handlers is the prerogative of the application developer who uses your library. The application developer knows their target audience and what handlers are most appropriate for their application: if you add handlers ‘under the hood’, you might well interfere with their ability to carry out unit tests and deliver logs which suit their requirements.

[yarikoptic]

Thank you @jwodder! One immediate aspect/"application" is logging during testing -- should log handler setup be added into a fixture?

[yarikoptic]

may be should be ok to enable it only if DANDI_LOG_LEVEL env var is present

[jwodder]

@yarikoptic pytest already captures logs, and there's already a fixture for setting the log level during tests.

[yarikoptic]

ah ok -- let's proceed then