mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2023-04-25 14:30:27 -04:00
parent 97d10f2f44
commit 6b77c02be9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 35 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_3_3f0872f13160a77a82bd5a95fc3f397d._comment
View file

@ -12,6 +12,13 @@ caused it, and so an exit status is not enough information.
So the additional json would need to include the filename that didn't
exist.
[this closed todo](https://git-annex.branchable.com/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/)
argues persuasively that --json-error-messages cannot be extended to
include these errors as-is. In particular, putting them in the current
json would mean outputting a record without a "key" field in situations
where that field is always present, so json consumers might
misbehave without it.
bpoldrack makes a good point
[here](https://github.com/datalad/datalad/pull/6510#issuecomment-1057320621):
@ -24,7 +31,7 @@ bpoldrack makes a good point
So eg:
{"exception":"UNIQUEID", "file", "foo", "error-messages":["foo not found"]}
{"exception":"UNIQUEID", "file":"foo", "error-messages":["foo not found"]}
That seems about right to me, and it future proofs git-annex to be able to
report other exceptions in json output later on.

27
doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_4_0217c8acd2a9eb3bba1fc497856cd96a._comment Normal file
View file

@ -0,0 +1,27 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2023-04-25T17:49:23Z"
content="""
What should enable that new json output for exceptions,
--json-error-messages or a new option like --json-exceptions?
The risk is that, since this is a new object type, it breaks a json
consumer that expects to find a `{"command":...}` object.
I do think that git-annex should be free to add new fields to existing json
objects. But adding a new object type seems considerably more risky.
git-annex has never done that before (eg --json-progress outputs the
"command" object with updated values).
I took a look at datalad's parsing of json from git-annex, to see what it might
do if it got a new object type unexpectedly. I'm not convinced it wouldn't
misbehave. For example, in `datalad/interface/results.py` `annexjson2result`:
res['status'] = 'ok' if d.get('success', False) is True else 'error'
Without a "status" field this will yield "error" which could go on to
cause unexpected behavior
So, I think this would need to be a new --json-exceptions option.
"""]]