ENH: datalad shell-completion helper #5544
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
@@ Coverage Diff @@
## maint #5544 +/- ##
- Coverage 90.19% 84.77% -5.42%
Files 296 295 -1
Lines 42055 42081 +26
- Hits 37930 35673 -2257
- Misses 4125 6408 +2283
Making shell-completion into a full featured new type of interface to enjoy all the levels of decoration for results evaluation, so we could even call it as dl.shell_completion(result_xfm='relpaths') To be appreciated while listening to https://www.youtube.com/watch?v=u9Dg-g7t2l4
yarikoptic added a commit to yarikoptic/datalad that referenced this pull request
Apr 15, 2021
…LDSTYLE_COMMANDS ATM it is needed to define _no_eval_results attribute to signal docbuilder to not populate docs for all the additional kwargs provided by @eval_results. Some commands even acquired @eval_results (e.g. create_sibling) but still had that attribute still set to True for unknown reason (probably just an effect of the decentralized logic during RFing). The effect of this was not mentioned probably because outside users/developers do not care to look up for those possible additional kwargs, and "core" developers simply know about them. I believe a similar situation was with common options defined at top level for datalad (--on-error, etc) -- since old interfaces did not care to return/yield structured records, they could (and still can) be provided but have no real effect on anything. So even though I had to tune up some tests in interfaces/tests/test_base.py I expect them to be of no negative effect. This change ENHs @eval_results to add _eval_results attriute to the wrapper, so outside logic could consistently decide to either add docstrings AND to handle all those additional kwargs. Even though we would still have some common options which are not applicable to interfaces which have no @eval_results, I expect situation to not differ pragmatically in that regard. As a result it should no longer require listing of OLDSTYLE commands. I can see how some developers might take it as undesired effect since now there would be no hardcoded listing of commands to RF or get rid of. Since we define a single Interface per file, analogous check could be done e.g. via $> git grep -l 'class.*(Interface)' | xargs grep -L @eval_results | grep -v -e '/test_' datalad/distribution/create_sibling_github.py datalad/distribution/create_test_dataset.py datalad/interface/add_archive_content.py datalad/interface/ls.py datalad/interface/test.py datalad/support/sshrun.py in the core codebase (so we would indeed loose some hits from extensions). But to me, and with shell-completion (datalad#5544) and sshrun helpers as use cases, it seems more of a matter of the fact that not all Interfaces should provide fancy results handling: they might be leaf interfaces not intended for nesting in a larger logic, not operate on datasets or be generators, have no associated with their action paths, etc. I really see no reason to complicate their code with more code to accomplish the same mission and possibly only to complicate debugging. I think we should allow for those to co-exist in peace with fancy @eval_result'ed interfaces. If we decide to allow for "simple" interfaces (for such helpers as above), we might want to RF further to derive an InterfaceWithResults to avoid ad-hoc _has_eval_results_call, which this PR introduces, and/or to avoid explicit addition of the @eval_results for every __call__ of every InterfaceWithResults. The above witch hunt also could be carried through a simple grep 'class.*(Interface)'.
OP considers this work done, and requests review/merge
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.