Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use serde to serialize-deserialize configs, including yaml #1630

Closed
CreepySkeleton opened this issue Jan 10, 2020 · 4 comments
Closed

Use serde to serialize-deserialize configs, including yaml #1630

CreepySkeleton opened this issue Jan 10, 2020 · 4 comments
Labels
C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this

Comments

@CreepySkeleton
Copy link
Contributor

Summary

Implement serde::Serialize/Deserialize for clap::App so it could be deserialized not only from a YAML file, but from any other format.

Motivation

Currently, yaml supports deserializing only from YAML via App::from_yaml. This restricts users to only the one blessed format, while the layout of clap::App is pretty simple on it's own and can be expressed in many config formats, such as JSON, TOML, .plist to name a few.

Supporting only the chosen one format is kind of inane nowadays, when we have serde, which handles the differences between formats in a generic way.

Not to mention a number of "YAML is too WTF-full format for config files" considerations. Some users (myself included) would happily move to TOML if it was supported out-of-box.

User experience

As for users of clap who only interested in YAML, nothing would change. From "user experience" side, there's no actual difference between

let yml = load_yaml!("file.yml");
let app = App::from_yaml(&yml);

and

let config = std::fs::File::open("file.yml").expect("No file.yaml!");
let app: App = serde_yaml::from_reader(config).unwrap();

But users interested on other formats, like TOML, JSON, you name it, could really make use of this feature.

Implementation

I gave a quick look-over to App and Arg layout and I'm fairly certain that Serialize and Deserialize can be simply derived.

Related issues

#918: Serializing to / deserializing from JSON. @kbknapp agreed this feature would be pretty useful.

#853: use serde_yaml since it provides much more useful error messages.

@jonericcook
Copy link

Would this feature allow for the following behavior?

./examplecli helpdump --json helpdump.json

and/or

./examplecli helpdump --stdout

The helpdump.json and stdout would contain all the information about how to use examplecli, essentially the --help for each command and subcommand with all the descriptions and arg type input.

The reason I ask because I have a handful of rust binaries that use clap and i would like to be able to call, for example, the helpdump command to get a json object that tells me how to interact with the binary so I can programmatically use the binary from another language.

I guess in a nut shell i'm asking for a rust program that uses clap to be able to output a .json file and/or a json string to stdout that describes how to use it so that it (the rust program) can be used by another program just by ingesting the .json/json string.

@pickfire
Copy link
Contributor

Maybe we could also merge configuration with the commands, with the configuration in file overwritten by the configuration specified by command arguments?

@throwaway1037
Copy link

I think RON should be supported.

Also, I think DSL support should only cost compile time and be baked into the binary, with no cost at runtime since it's essentially a declarative specification of the command-line arguments for the program. The alternative is reading the file at runtime, and then having to distribute it with the program, which is slower and uses more storage space. I don't know which is the current behaviour.

@epage
Copy link
Member

epage commented Dec 9, 2021

We have decided to deprecate the YAML API. For more details, see #3087. If there is interest in a YAML API, it will likely be broken out into a clap_yaml and developed independent from the core of clap.

@epage epage closed this as completed Dec 9, 2021
@epage epage added the S-wont-fix Status: Closed as there is no plan to fix this label Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this
Projects
None yet
Development

No branches or pull requests

6 participants