JSON output option

[cdalvaro]

It would be nice to have a parameter like --json when listing or searching apps.

I have tried to parse the current output, which is not very difficult, but it can stop working at any time if the output format is changed.

This could help to create an API for automation.

For example, instead of:

mas list
424389933 Final Cut Pro (10.4.4)
409183694 Keynote (8.3)
409203825 Numbers (5.3)
409201541 Pages (7.3)

get something like:

mas list --json
[{"name":"Final Cut Pro","version":"10.4.4","id":424389933},{"name":"Keynote","version":"8.3","id":409183694},{"name":"Numbers","version":"5.3","id":409203825},{"name":"Pages","version":"7.3","id":409201541}]

[
  {
    "name": "Final Cut Pro",
    "version": "10.4.4",
    "id": 424389933
  },
  {
    "name": "Keynote",
    "version": "8.3",
    "id": 409183694
  },
  {
    "name": "Numbers",
    "version": "5.3",
    "id": 409203825
  },
  {
    "name": "Pages",
    "version": "7.3",
    "id": 409201541
  }
]

[phatblat]

Great idea. I've been thinking along the same lines. The existing output formatting is very ad-hoc and inconsistent between commands without much design behind it. App names can sometimes be quite long due to SEO efforts and thus parsing errors could arise even with the existing formats if numbers and special characters are embedded. I want to add a formatting layer so that the various supported formats can easily be toggled.

Is the a specific use case you are looking to automate? Are there any attributes that you would like to see added? The current text output doesn't lend itself to including a lot of data, but this output could be a lot more verbose in JSON as it doesn't need to fit easily on a terminal screen.

[cdalvaro]

I'm working on a SaltStack module/state for automating the management of Mac App Store applications. (That is the reason of my comment in #89)

Your mas package is perfect for this purpose, but I need some information, mainly the three parameters commented in the description (id, name and version), in order to control changes, and a stable API that won't change too much in time. (That is the reason of this suggestion)

At the moment, I don't have found any situation in which I have needed more information than the three parameters requested. Although, by returning a JSON, more information could be added later without breaking the API.

[cdalvaro]

Hi! Is there any progress on this issue??

[phatblat]

It would be neat to have a --json5 option too, mostly for the unquoted keys.

[rgoldberg]

Maybe the --json option should be on mas (like mas --json list), not on the subcommand (not like mas list --json), because any command should be able to format its output as json (even the commands that don't normally have any output could change to have some output later).

Should error or warning messages also be output as json? Or could we limit json to stdout, while using normal text logging messages for stderr?

[cdalvaro]

Maybe the --json option should be on mas (like mas --json list), not on the subcommand (not like mas list --json), because any command should be able to format its output as json (even the commands that don't normally have any output could change to have some output later).

Should error or warning messages also be output as json? Or could we limit json to stdout, while using normal text logging messages for stderr?

I'm fine with this, as long as we have a way to retrieve installed apps in JSON format.

[rgoldberg]

@cdalvaro Thanks.

Also, I would default to outputting all the data from any JSON we obtain, rather than filtering out values. Filtering can be done by piping stdout to jq or a similar program.

The results we get seem to be in standard JSON, not abbreviated JSON5. Should we ensure it's proper JSON, or just return what we get? If somehow invalid JSON, easiest to just output it to stderr, unless we see a consistent incorrect formatting that can be deterministically massaged into valid JSON. I also assume that we shouldn't sort the JSON files.

Let me know if you disagree.

[cdalvaro]

I'm happy with that!

To avoid format issues, the best is to redirect everything to stderr except the json itself, when the json option is present.

[rgoldberg]

@cdalvaro Agreed. Thanks.

[rgoldberg]

See #63 (comment), which includes a discussion of different field names from different sources used for different commands (like list & info). I think we should standardize field names across all output/arguments. Once we resolve how to handle this situation, we can progress with implementations.