RM deprecated (promoted to .core.local.run) in 0.12 release interface.run and saver option

[yarikoptic]

• datalad-container is expected to fail, PR there RF: use datalad.core.local.run instead of datalad.interface.run datalad-container#120

[kyleam]

I don't think these changes should be made in the rc stage. And in general there is no reason this needs to be removed right now.

[yarikoptic]

agree in general (thus did not label it for 0.13.0 milestone although said "likely" in containers PR ;) ). Will mark for 0.14.0.

And in general there is no reason this needs to be removed right now.

My selfish rationale for removal of those deprecated interfaces - pycharm allows to quickly open an file by starting to type its name (like run). Having multiple run, diff, etc across code base complicates navigation etc. Since I think we all would agree that they should be removed, I did not want to delay submitting a PR since I would have just forgotten and it would lurk around for longer.

[codecov]

Codecov Report

Merging #4583 into master will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4583   +/-   ##
=======================================
  Coverage   89.63%   89.63%           
=======================================
  Files         285      284    -1     
  Lines       38685    38677    -8     
=======================================
- Hits        34677    34670    -7     
+ Misses       4008     4007    -1     

Impacted Files	Coverage Δ
datalad/core/local/run.py	99.13% <ø> (+0.42%)	⬆️

---

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 e7e42a4...ec4afad. Read the comment docs.

[yarikoptic]

Logistics wise: should we establish next or 0.14 branch to which we merge such changes? Otherwise we would need to keep such PRs open until we decide that master is seeing no new features and destined for the new "major" release. IMHO version based (0.14) is better but I am ok with next.

[kyleam]

Logistics wise: should we establish next or 0.14 branch to which we merge such changes?

If you think that is useful, that's fine by me. My opinion is that creating another branch to merge in changes like this adds no value and that merging this can wait until a release. The code being removed by this PR is not a maintenance burden.

FWIW, aside from stylistically disliking branch names that consist only of versions, I'd find 0.14 confusing as a name because I'm used to branches with versions being a track for a lesser version tick (e.g., the last tag in maint-2.23 could be, say, v2.23.3).

[mih]

I do not see a need for another branch. Admittedly, I already had a hard time adjusting to maint. I am also not developing something for the release after the coming one. And I am also used to seeing lots of open PRs. It would become an issue for me, when there are 6 months of inactivity of a perfectly mergable PR, because I would close it as stale ;-)

[kyleam]

It would become an issue for me, when there are 6 months of inactivity of a perfectly mergable PR, because I would close it as stale ;-)

I think there are deeper issues to worry about if 0.13.0 stays in the rc phase for 6 months.