Fix all logging to use %-interpolation and not .format, sort imports in touched files, add pylint-ing for % formatting in log messages to tox -e lint

[yarikoptic]

#7117 made me look into tightening our automated linting. Adding pylinting for a single warning/error to start with:

W1202: Use lazy % or % formatting in logging functions (logging-format-interpolation)

which I believe nobody would doubt to be a good thing to do.

• any objections?
• fix the code
• later (other PRs): enable more checks while at it or may be postpone to follow up dedicated PRs, but worth listing here may be (I was looking for the one in BF: Fix add-archive-contents try-finally statement by defining variable earlier #7117 like use of undefined variable but pylint didn't warn about that :-/ )

[appveyor skip]
[travis skip]

edit: had to cancel appveyor manually -- for some reason it ignored the annotation I gave

[jwodder]

@yarikoptic I've fixed all occurrences of the W1202 lint.

[yarikoptic]

travis -- filed #7126 and restarted , appveyor -- looked like some ssh issue

[gw0] PASSED ../datalad/core/local/tests/test_save.py::test_add_mimetypes 
1185../datalad/core/local/tests/test_save.py::test_gh1597 channel 22: open failed: connect failed: open failed
1186channel 22: open failed: connect failed: open failed
1187channel 22: open failed: connect failed: open failed
1188channel 22: open failed: connect failed: open failed
1189channel 22: open failed: connect failed: open failed
1190channel 22: open failed: connect failed: open failed
1191

restarted

[codecov]

Codecov Report

Base: 54.86% // Head: 90.56% // Increases project coverage by +35.70% 🎉

Coverage data is based on head (1d6461d) compared to base (da44dbc).
Patch coverage: 94.49% of modified lines in pull request are covered.

❗ Current head 1d6461d differs from pull request most recent head e34ab44. Consider uploading reports for the commit e34ab44 to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##            maint    #7118       +/-   ##
===========================================
+ Coverage   54.86%   90.56%   +35.70%     
===========================================
  Files         355      355               
  Lines       46479    46610      +131     
  Branches     6327        0     -6327     
===========================================
+ Hits        25499    42213    +16714     
+ Misses      20937     4397    -16540     
+ Partials       43        0       -43     

Impacted Files	Coverage Δ
datalad/tests/utils_pytest.py	89.02% <ø> (+16.14%)	⬆️
datalad/utils.py	86.07% <0.00%> (+16.06%)	⬆️
datalad/support/archives.py	85.71% <88.23%> (+14.98%)	⬆️
datalad/support/annexrepo.py	90.39% <90.90%> (+14.03%)	⬆️
datalad/distribution/create_sibling.py	65.43% <91.66%> (-4.57%)	⬇️
datalad/support/network.py	87.33% <92.30%> (+13.59%)	⬆️
datalad/cli/main.py	82.00% <100.00%> (+6.00%)	⬆️
datalad/customremotes/archives.py	90.30% <100.00%> (ø)
datalad/distributed/create_sibling_ria.py	85.71% <100.00%> (+0.08%)	⬆️
datalad/interface/base.py	92.26% <100.00%> (-3.12%)	⬇️
... and 227 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[bpoldrack]

Generally, looks good to me.
But why maint? Seems to me it would be easier to resolve in master (for example metadata removal).

[yarikoptic]

Generally, looks good to me. But why maint? Seems to me it would be easier to resolve in master (for example metadata removal).

because it is a bug to use f-strings in logging. Most likely most of them are benign and should never result in triggering some condition which would lead to datalad errorring out but we don't know. This actually gives me an idea to add some %d into obscure filename -- might be "fun" ;) edit: not needed -- we already have %b5 as one of the possible parts of the most obscure filename:

❯ python -c 'from datalad.tests.utils_pytest import OBSCURE_FILENAME; print(OBSCURE_FILENAME)'
 |;&%b5{}'"<>ΔЙקم๗あ .datc 

so if there was a log line which had this already, might have triggered that condition.

[yarikoptic]

for example metadata removal

BTW IMHO it is a bit misleading to name it "removal" -- it is a "move to -deprecated" so not really "fire and forget", and indeed it would cause conflicts and then lack of similar fix in deprecated since most likely people just would not care to fix it there, although that code would still be there and might even be used by some. But that is ok

[yarikoptic]

another reason -- to avoid lingering merge conflicts from maint to master on any PR which touches those log lines...

anyways -- if no strong objections, I would prefer to merge tomorrow and proceed with preparing merge into master.

[bpoldrack]

Ok, let's proceed then.

[yarikoptic-gitmate]

PR released in 0.17.9