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

Attention: Patch coverage is 96.33028% with 4 lines in your changes missing coverage. Please review.

Project coverage is 90.93%. Comparing base (da44dbc) to head (e34ab44).
Report is 1135 commits behind head on maint.

Files with missing lines	Patch %	Lines
datalad/support/archives.py	88.23%	2 Missing ⚠️
datalad/support/annexrepo.py	90.90%	1 Missing ⚠️
datalad/utils.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            maint    #7118      +/-   ##
==========================================
+ Coverage   89.37%   90.93%   +1.56%     
==========================================
  Files         355      355              
  Lines       46498    46506       +8     
  Branches     6327     6327              
==========================================
+ Hits        41559    42292     +733     
+ Misses       4924     4199     -725     
  Partials       15       15              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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