ATM it is a formatted text (click to expand)
$> git annex initremote myrsync type=rsync --whatelse
shellescape
avoid usual shell escaping (not recommended)
(yes or no)
rsyncurl
(required) url or hostname:/directory for rsync to use
chunk
size of chunks (eg, 1MiB)
encryption
how to encrypt data stored in the special remote
(hybrid or none or pubkey or shared or sharedpubkey)
embedcreds
embed credentials into git repository
(yes or no)
mac
how to encrypt filenames used on the remote
(HMACSHA1 or HMACSHA224 or HMACSHA256 or HMACSHA384 or HMACSHA512)
keyid
gpg key id
keyid+
add additional gpg key
keyid-
remove gpg key
exporttree
export trees of files to this remote
(yes or no)
importtree
import trees of files from this remote
(yes or no)
which would make it necessary to establish a possibly fragile parsing by any tool which would like to programmatically obtain/use/expose those options.
It would be great if there was a way to trigger such listing be output in more friendly for machines form? e.g. a json dictionary alike
{
"rsyncurl": {
"required": True,
"description": "url or hostname:/directory for rsync to use"
},
"shellescape": {
"description": "avoid usual shell escaping (not recommended)",
"choices": ["yes", "no"]
},
...
}
Looking at the protocol I see no indication of "required" or "choices" to be actually explicitly provided by the remote fields, so I guess just supposed to be included in the text, so may be given current state of things, aforementioned dictionary would be simply {"NAME": "DESCRIPTION"}
, which someone makes this proposed TODO less valuable.
My design process for this feature included almost getting stuck on wanting some kind of types for the values, and way to track which options are required, or exclusive of other options, or dependencies of other options, etc. All stuff that eg, an applicative option parser can support quite well, but it would complicate the external protocol enourmously, if it could be represented at all in it. So I had to eliminate all that.
I think it's fairly uncommon for tab completion to do anything special about required parameters, or even mutually exclusive options (although git-annex tab completion does handle the latter), and while I can imagine a gui interface marking an input field as required, it seems that would be the least of its problems if it doesn't know what kind of control to use for the field?
It would be easy to add --whatelse-json, but it would be limited to the name, a description of the purpose of the field, and maybe a description of the expected value or list of valid values. I'm unsure about the utility of that..
I'm still not seeing much of an application for this, but since I've been adding --json support to most git-annex commands anyway recently, and got to initremote, I did go ahead and make --whatelse --json work.
Currently only the field name and description, and a description of the allowed values are in there. It might be possible to add more information like type or required or not, but I'd want to work with someone who was consuming that information to do that.