json support

[rsteube]

Request

Lots of frameworks and languages have json support out-of-the box but yaml would introduce an additional dependency.

Proposed solution

Provide secondary support for json (import/conversions).

Anything else?

No response

[maxlandon]

Is there any advances on this ?
Curious to know if providing support for JSON would be a complicated endeavor.

Being even bolder: I think always think of spf13/viper for parsing serialized configuration/spec files.
There is a wide range of ways to parse files/structs (different levels of granularity, initialization, etc).

Also, you end up with full support for at least 3-4 major formats, and the other ones supported by viper are just added bonus, should anyone wish to write a spec into an INI file...

[rsteube]

It shouldn't be too complicated as the spec is rather simple.
Rather this is just an idea i am considering but might end up deciding against.
YAML should continue to be the main format and this might lead to a bit of a mess.
There are enough tools to convert formats as is the only question would be how to handle macros.

Think viper had quite a lot of dependencies and wouldn't give much advantages in this case.

[maxlandon]

Viper: yes I forgot how large the dependency list is, forget about this.

JSON: if I'm not mistaken, everything supported on YAML is also supported on JSON. Just thinking out loud about potential compatibility problems down the road.
Actually, you already export the completions with matcher/suffix strings as JSON in the carapace libraries/binaries.
To me that means that you already have quite a lot of confidence when it comes to pass weird strings in serialized format. Again, thinking out loud.

Third party tools for conversion: maybe you didn't mean this the way I heard it. However if you did more or less, I would like to argue that asking people to manage third party tools for this matter is not practical.
In addition, given that your entire schema is quite simple, carapace should be able to take responsibility for any conversion/serialization of it.
(Please hear my very respectful voice when reading "should be able")

Happy to help if you'd like a mock or something.

[rsteube]

There shouldn't be any issues with json just maybe having the annoyance of having both tags on the command struct.
The only thing i was wondering about is whether the macros, which are parsed as yaml, should support json as well.

With third-party tools i means ones like yj as it might be better to explicitly not support a different format than yaml.

[maxlandon]

Macros: can't say anything as I've neither tested nor looked at the macros code (just flown above it once).

Yj tool: it can be used as a library, so you might be interested in this if you want to remain self-contained.
In this case I see more or less two possible paths:

• You decide that exporting should be done in format A to/from format B in your carapace internal code. That is, you consume the yj library as a developper only. (In the spirit of the carapace <shell> sourcing invocation where the shell positional is optional...)
• Either/or/in some places, you export a --format flag in the various caparace CLIs when they need/accept forcing a specific format.
  The "implementation" of this flag is just some sort of "reexport" or "wiring" to the corresponding flags of the yj tool (but again, this wiring is done in your internal code).

To be clear, uses of the pronoun "your" targets your carapace internal code, not any consumer of the libraries.

[rsteube]

Yes providing the conversion is something i have considered as well as the dependencies for it are already present anyway (no need for yj in this case).
What i'm mostly against at the moment is having direct support of an other format than yaml (e.g. placing json in ~/.config/carapace/specs).

[maxlandon]

By the way, related to #655, at some point it might be very very useful to load completion specs from directories/files/streams outside of .config/carapace/specs/.

I know that it's possible to write a completer for this, with the various exports/command function helpers in your library, but I am pretty sure that this will be a pain when registering commands in bulks (which is the case in the other repo issue mentioned above).

That is, it's easy for a given positional completer to link to another command completer spec (a la git-command), but it requires every command to declare this positional completer.

Take this comment with a pinch of salt though, I've not experimented enough with this for being entirely positive.

[maxlandon]

For not allowing JSON into the specs directory, I only have obvious suggestions for it (add a json subdir, or some other ideas).

I'm pretty sure you already have those in mind anyway, so I can't help further here.

[maxlandon]

Another ping here to know if there are advances as far as devising what's possible and what's not:

• JSON support either not in .carapace/specs/ or in a subdirectory, or if support for both formats in the same directory is possible.

• If loading specs from other directories is feasible (since it would be very much needed by some applications)

• If some mechanism can be devised to load multiple specs in bulk, as subcommands of a given root.
  I imagine some way to programmatically register these specs files/directories from the carapace library:

carapace.ReadSpec(rootCmd, "path/to/spec/dir-or-file")

This would bind all specs found in the dir as subcommands of the rootCmd: they would be proposed as completions along with any command/flag tree already found on the command.

Maybe there is an equivalent to that in carapace already that I would have missed ?

Will try to open a PR for the sake of mocking this.

[rsteube]

JSON support either not in .carapace/specs/ or in a subdirectory, or if support for both formats in the same directory is possible.

Haven't decided to actually support JSON yet.

If loading specs from other directories is feasible (since it would be very much needed by some applications)

It's at least planned for carapace-bin: carapace-sh/carapace-bin#1336

If some mechanism can be devised to load multiple specs in bulk, as subcommands of a given root.

I'm considering a dot-delimited approach: #91 (comment)