While looking for various spots where core.quotepath=true
is now treated
by git-annex
(ref)
I found that unannex
doesn't have --json
and we do some really ad-hoc
splitting which fails with spaces and we never actually tested enough.
With all the quotepath
and other fun, we really should get
machine-readable, thus --json
, output for all annex commands IMHO. E.g.
unannex
has recently come up within treatment of BIDS datasets, and so
far we were lucky that BIDS filenames do not allow for spaces in the
filenames, but there is always derivatives/
and sourcedata/
which are
not formalized and could have all kinds of odd filenames.
These commands have been updated to support --json:
- git-annex-unannex
- git-annex-rmurl
- git-annex-log
- git-annex-fix
- git-annex-setpresentkey
- git-annex-rekey
- git-annex-undo
- git-annex-migrate
- git-annex-addunused
- git-annex-dropunused
- git-annex-expire
- git-annex-trust
- git-annex-semitrust
- git-annex-untrust
- git-annex-dead
- git-annex-describe
- git-annex-unused
- git-annex-init
- git-annex-reinit
- git-annex-reinject
- git-annex-renameremote
- git-annex-importfeed
- git-annex-merge
- git-annex-upgrade
- git-annex-initremote
- git-annex-enableremote
- git-annex-configremote
- git-annex-uninit
These commands have been reviewed and should not support json:
(Discussion welcome of course if you disagree..)
- git-annex-contentlocation, git-annex-lookupkey, git-annex-calckey, (plumbing, output already machine parseable)
- git-annex-setkey (plumbing)
- git-annex-checkpresentkey (plumbing, has batch interface with machine parseable output)
- git-annex-readpresentkey (plumbing, no output)
- git-annex-matchexpression (no output)
- git-annex-list (because it's a compact display of whereis so no new information)
- git-annex-direct (deprecated noop)
- git-annex findref (deprecated, can use find to do same thing)
- git-annex indirect (deprecated noop)
- git-annex proxy (deprecated and displays git command output so nothing structured)
- git-annex-pre-commit (used internally)
- git-annex-post-receive (used internally)
- git-annex-smudge, git-annex-filter-process (run by git)
- git-annex-p2p (used internally)
- git-annex-shell (run by git)
- git-annex-assistant (too high level)
- git-annex-watch (too high level and a daemon)
- git-annex-webapp (too high level)
- git-annex-test, git-annex testremote (ouput not useful to consume and generated by tasty)
- git-annex-fuzztest (output not useful to consume)
- git-annex-map (already generates machine-parseable output file, stdout is incidental)
- git-annex-transferkey, git-annex-transferkeys (plumbing)
- git-annex-transferrer (plumbing, has its own protocol)
- git-annex-resolvemerge (no output except to stderr)
- git-annex-diffdriver (run by git)
- git-annex-restage (no output)
- git-annex-benchmark (no useful output, and output generated by criterion)
- git-annex-config (only useful output is when it outputs the current value of a config setting, which is already machine parseable)
- git-annex-required, git-annex-wanted, git-annex-groupwanted (like git-annex-config)
- git-annex-mincopies, git-annex-numcopies (like git-annex-config)
- git-annex-group (like git-annex-config)
- git-annex-ungroup (no point if group doesn't)
- git-annex-filter-branch (output is already machine parseable)
- git-annex-remotedaemon (plumbing, speaks its own protocol)
- git-annex-repair (seems unlikely to be useful to integrate with something?)
- git-annex-vicfg (interactive)
- git-annex-enable-tor (prompts for password, more or less interactive so seems unlikely to be useful to jsonize)
- git-annex-multicast (runs uftp and displays its output)
- git-annex-whereused (output is already machine parseable)
- git-annex forget (output does not contain anything useful to a program)
- git-annex-adjust, git-annex-vadd, git-annex-vcycle, git-annex-vfilter, git-annex-view, git-annex-vpop (no output that would be useful to a program using these. They enter a new branch and git branch will tell what it is.)
- git-annex-inprogress (output is already machine readable)
- git-annex-sync (while it would be pretty easy to support, it outputs different types of messages depending on what remotes it syncs with and what needs to be done. Eg, copy to remote, or export to remote, or import from remote. Each would be a different format of json message, which violates the principle that all git-annex json output should be discoverable by simply running the command. And of course, everything it does can be done by other commands, which can support json without having that problem.)
- git-annex-version (--raw already exists, and the other output is fairly machine parseable already. It would be possible to jsonize the output to make it possibly more machine parseable. But I'm doubtful that would be useful. Also, this command needs to work when not run in a git-annex repo, and usual json display needs the Annex monad. So it would need to use aeson manually.
Calling this done. Of course, if I was wrong about any of the commands above not needing json, just let me know. --Joey
I agree generally, anything that is not already explicitly machine parseable should support --json (and --json-error-options will be available for free once that's added)
I'd exclude things like
git-annex find
which have --format that can be used similarly; and a separate json output would not be very useful for find anyway probably?I've added a list of commands that currently don't support --json above.
Did unannex already, as it was trivial.