importfeed: Support --json and --json-error-messages and --json-progress

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

importfeed: Move error to where --json-error-messages can capture it

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

importfeed: Support -J (and work toward supporting --json)

Both -J and --json needed importfeed to be refactored to use commandAction.

That was difficult, because of the interrelated nature of downloading feeds
and then downloading files from feeds, both of which needed to use
commandAction. And then checking for problems in feeds has to come after
these actions, which may be run as background jobs.

As for --json support, it's most of the way there, but still has some
warts, so I didn't enable jsonOptions yet. The warts include:

- An initial empty json record is displayed by getCache.
- Input is not populated, should be feed url
- feedProblem at end will not be captured by --json-error-messages
  (see FIXME)

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

renameremote: Support --json and --json-error-messages

Seems unlikely to be useful, but it works so

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

factor out maybeAddJSONField

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

reinject: Support --json and --json-error-messages

Also fix support for operating on multiple pairs of files and keys.

Moved notAnnexed to inside starting, so error message will get into the json.

Cannot include the key in the starting as it's not known yet, so instead
add it to the json later.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

reinit: Support --json and --json-error-messages

Basically same concerns as init..

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

init: Support --json and --json-error-messages

Dunno how useful this will be, since about all that's accessible from
the json is whether it succeeded or failed, and the error messages
which were already on stderr.

Note that, when autoenabling a special remote, it would be possible for
one to stop and prompt or output not using Messages and so not output as
part of the json. I don't think that happens, but I'm not 100% sure
something doesn't manage to break it. Of course, the same could be the
case for commands that transfer objects. Using Annex.Init.autoEnableSpecialRemotes
in --json mode would avoid the problem, but I've chosen to wait until I
know it's needed to use it.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

unused: Support --json and --json-error-messages

Generalized AddJSONActionItemField to allow it to add several fields. Not entirely
happy with that, since the names of the fields have to be carefully chosen to
not conflict with other json fields. And fields added that way can't be parsed
back in FromJSON, except for the "fields" field that is special cased for metadata.
Still, I couldn't see another way to do it.

Also, omit file:null from the json output. Which does affect other commands,
eg git-annex whereis --all --json. Hopefully that won't break something that expects
a null file. If it did, that could be reverted, but it would be ugly to have
file:null in the unused --json

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

remove spam

remove spam

Added a comment: The Best solution for missing files

removed

Added a comment: A nice solution

Added a comment: The best option of s3 mac client

Added a comment: The best option of s3 mac client

Revert "update"

This reverts commit 940f9ee9ce6a688dbf97b22c84941eabf67a8694.

update

oops

expire, trust et al, dead, describe: Support --json and --json-error-messages

For expire, the normal output is unchanged, but the --json output includes the uuid
in machine parseable form. Which could be very useful for this somewhat obscure
command. That needed ActionItemUUID to be implemented, which seemed like a lot
of work, but then ---

I had been going to skip implementing them for trust, untrust, dead, semitrust,
and describe, but putting the uuid in the json is useful information, it tells
what uuid git-annex picked given the input. It was not hard to support
these once ActionItemUUID was implemented.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

addunused, dropunused: Support --json and --json-error-messages

This also changes addunused to display the names of the files that it adds.
That seems like a general usability improvement, and not displaying the input
number does not seem likely to be a problem to a user, since the filename
is based on the key. Displaying the filename was necessary to get it and the key
included in the json.

dropunused does not include the key in the json. It would be possible to
add, but would need more changes. And I doubt that dropunused --json
would be used in a situation where a program cared which keys were
dropped. Note that drop --unused does have the key in its json, so such
a program could just use it. Or could just dropkey --batch with the
specific keys it wants to drop if it cares about specific keys.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

comment

Added a comment: out of date git-annex

Added a comment: Invalid argument `whereused'

update

migrate, undo: Support --json and --json-error-messages

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

rekey, setpresentkey: Support --json and --json-error-messages

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

update

fix: Support --json and --json-error-messages

And triaged out some commands that don't need to support these options.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

log: Support --json and --json-error-messages

Also in passing the --all display was fixed up to not quote keys like filenames.

Note that the check added to compareChanges was needed to avoid logging when
nothing changed.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

remote tailing 's' from log --raw-data

log: When --raw-date is used, display only seconds from the epoch, as
documented, omitting a trailing "s" that was included in the output
before.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

rmurl: Support --json and --json-error-messages

The json does not include an url field, but it does have an input field that is
"file url" when using --batch and ["file", "url"] when using the command line.
I chose not to change that because it would complicate batchInput.
An url field could be added if it turns out to be useful.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

moved log and rmurl to the top as the one we use AFAIK

unannex: Support --json and --json-error-messages

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

comment

plea for --json for unannex and other commands

Added a comment: adding all files or only in current directory?

Added a comment: Groups comprised of archive drives of various size

forwarded git bug

comment

comment

beat my head against this bug for a couple hours

comment

initremote: Avoid creating a remote that is not encrypted when gpg is broken

checksize was applied lazily, so the exception didn't happen until the
remote was set up.

Sponsored-by: k0ld on Patreon

comment

Merge branch 'master' of ssh://git-annex.branchable.com

fix reversion in display of fatal exceptions

fdac66ae10a7022326d1470862c93fd191216e61 lost the "git-annex:" prefix,
which broke datalad's parsing of an error message (ugh)

Also, don't use warningIO because it displays a blank line to stdout,
which is also a behavior change from before, and does not seem
necessary.

Sponsored-by: Brock Spratlen on Patreon

Added a comment

fixed related issue

back compat fix for info --json on unknown item

This was changed in a0e6fa18eb3c16c3c8079bb41c18151e6ea8b554 in a way
that broke datalad, which expected to see a "file" field in the --json.

See https://github.com/datalad/datalad/pull/7372/commits/45ddd4b12ff637c6c77e982225c0e9d9eb53c1b6

comment

Added a comment: output

Added a comment

Added a comment: git-annex relaying syncs across remotes

Added a comment: What is the underlying reason for needing a two-way SSH connection

Added a comment

avoid annexFileMode special case

This makes annexFileMode be just an application of setAnnexPerm',
which avoids having 2 functions that do different versions of the same
thing.

Fixes some buggy behavior for some combinations of core.sharedRepository
and umask.

Sponsored-by: Jack Hill on Patreon

Support core.sharedRepository=0xxx at long last

Sponsored-by: Brett Eisenberg on Patreon

fix perms for core.sharedRepository

These two missed setting it.

It rarely matters that the journal gets the right perm. But, when using
annex.alwayscommit=false, someone else may come along later and want
to append to the journal file.

It probably never matters what the sentinal perms are, but for
completeness..

Sponsored-by: Luke Shumaker on Patreon

fix init .git/annex/ perms for core.sharedRepository

init: Bug fix: Create .git/annex/ and .git/annex/fsckdb/ directories with
permissions configured by core.sharedRepository.

The fsckfb being created happens to create .git/annex/ and it was not using
createAnnexDirectory. Probably a reversion partly, but maybe the database
directory was always created not honoring core.sharedRepository?

Sponsored-by: Noam Kremen on Patreon

Warn about unsupported core.sharedRepository=0xxx when set

This spams the user with a lot of messages, but it seems like busywork to
avoid that and only warn once, since this warning will go away when it gets
implemented.

Also fix parsing of the octal value.

Sponsored-by: Kevin Mueller on Patreon

rename errorid to message-id

Added a comment

Added a comment

avoid quoting spaces in git-annex find output to terminal

That's too much quoting, the user expects the filename to be copy and
pasteable. It would be ok to slash-escape space ('\ ')
which is what gnu find does, but it doesn't seem necessary either.

${escaped_file} has always quoted spaces though, so keep on doing it
there.

Sponsored-by: Nicholas Golder-Manning on Patreon

note

close and followup

json object for FileNotFound

When a nonexistant file is passed to a command and  --json-error-messages
is enabled, output a JSON object indicating the problem.

(But git ls-files --error-unmatch still displays errors about such files in
some situations.)

I don't like the duplication of the name of the command introduced by this,
but I can't see a great way around it. One way would be to pass the Command
instead.

When json is not enabled, the stderr is unchanged. This is necessary
because some commands like find have custom output. So dislaying
"find foo not found" would be wrong. So had to complicate things with
toplevelFileProblem having different output with and without json.

When not using --json-error-messages but still using --json, it displays
the error to stderr, but does display a json object without the error. It
does have an errorid though. Unsure how useful that behavior is.

Sponsored-by: Dartmouth College's Datalad project

Revert "--json-exceptions"

This reverts commit a325524454fdc45a61f91844efb3065f6e34b318.

Turns out this was predicated on an incorrect belief that json output
didn't already sometimes lack the "key" field. Since json output already
can when `giveup` was used, it seems unncessary to add a whole new
option for this.

Merge branch 'master' of ssh://git-annex.branchable.com

--json-exceptions

Added a --json-exceptions option, which makes some exceptions be output in json.

The distinction is that --json-error-messages is for messages relating
to a particular ActionItem, while --json-exceptions is for messages that
are not, eg ones for a file that does not exist.

It's unfortunate that we need two switches with such a fine distinction
between them, but I'm worried about maintaining backwards compatability
in the json output, to avoid breaking anything that parses it, and this was
the way to make sure I didn't.

toplevelWarning is generally used for the latter kind of message. And
the other calls to toplevelWarning could be converted to showException. The
only possible gotcha is that if toplevelWarning is ever called after
starting acting on a file, it will add to the --json-error-messages of the
json displayed for that file and converting to showException would be a
behavior change. That seems unlikely, but I didn't convery everything to
avoid needing to satisfy myself it was not a concern.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

upcase JSON

Added a comment

comment

update

comment

comment

update docs to account for exporttree

Added a comment: File visibility

removed

Added a comment

Added a comment

comment

Added a comment

comment

initial report on bad escaping

close

Added a comment

idea

analysis and followup