toml-rs VS clap-rs

I updated the toml<->json online converter after the ValueAfterTable error has been fixed with toml 0.6. Very nice to see progress on the toml and toml_edit crates.

use std::fs::File; use std::io::Write; use std::collections::BTreeMap as Map; use serde_derive::{Serialize, Deserialize}; #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type0")] enum FooBarTwo<'a> { FooBarOne { string1: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type1")] enum FooBarThree<'a> { FooBarFour { string2: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFour<'a> { black: &'a str, #[serde(borrow)] green: FooBarTwo<'a>, #[serde(borrow)] blue: FooBarThree<'a>, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFourList<'a> { // Uasing a Map to workaround a known bug (#303) when using top level Vec // see https://github.com/alexcrichton/toml-rs/issues/303 #[serde(borrow)] foo_bar_six: Map<&'a str, FooBarFour<'a>> } fn main() { let red = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let pink = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let mut white = Map::new(); white.insert("pink", pink); white.insert("red", red); let fbfl = FooBarFourList { foo_bar_six: white }; println!("\nTL: {:?}\n", fbfl); let filename = "./data/test.toml"; let data = toml::to_string(&fbfl).expect("Error serialising fbfl"); println!("\nTL as TOML: {:?}\n", data); let mut f = File::create(filename).expect("Unable to create file"); f.write_all(data.as_bytes()).expect("Error writing data to file"); let toml_in: FooBarFour = toml::from_str(&data).expect("Error deserialising fbfl"); println!("\n{:?}\n", toml_in); }

This is especially useful for data deserialization: Just by implementing the Serialize and Deserialize traits from the serde crate, the (almost) universally used serialization library in the Rust world, we can then serialize and deserialize our types to a lot of data formats: JSON, YAML, TOML, BSON and so on...

It looks like the fields are public now (https://github.com/alexcrichton/toml-rs/pull/455, https://docs.rs/toml/latest/toml/value/struct.Date.html), so just upgrading the crate should do it :-)

Pair that with Serde for serialization/deserialization (JSON, TOML, YAML, CSV/TSV, XML, URL query strings, etc.), Figment for configuration, and ignore for filesystem traversal with blacklist support, and Rust is a real joy for writing CLI utilities.

Added toml-rs-compatible API via the toml_edit::easy module for when developers want to ensure consistency between format-preserving and general TOML work, with one caveat.

A quick example off the top of the head of my head is some tests in the toml package. It has a few different approaches. One is to use macros as in parser.rs. In valid.rs and invalid.rs it uses macros to generate a separate test for each input file. This allows you to run just one individual test from the list. These examples aren't perfect, and there are more sophisticated test utilities (like insta) that can abstract the process of "here are a bunch of inputs, test them all".

I want to read a toml file with default value. I tried toml-rs but it doesn't allow for default values.

We will be using the library for Clap - A simple-to-use, efficient, and full-featured library for parsing command line arguments and subcommands.

I recently came across this question (and associated answer) on the clap repository. The answer given is a good one. But I wanted to expand with my own findings and practices, which spurred the motivation for this post.

We can also use tuple-like struct syntax and named-field struct syntax for enum variants within our enum; this is because unlike in other OOP languages, Rust enums are actually sum types. You can read more about how powerful Rust enums are in another article we wrote here. You can have optional arguments by simply wrapping the types in Option, but if you want to add a flag to a command you can use bool, since clap recognises that flags are either there or not there. Let's have a look at what this might look like:

I began by developing a wrapper for the CurseForge API, which turned out to be a lengthy and challenging process but constituted the bulk of the work. Next, I coded the CLI, which was relatively straightforward. Instead of using the clap crate, a Rust tool for generating CLIs, I opted for the following line of code:

By this time I had already gotten tired of parsing arguments by myself and had looked for something to help with that. I found a really dang good argument parsing library called clap. What makes it so cool is it's largely declarative for common uses. You simply mark up a struct with attributes, and the parser automatically generates the usage and all the argument parsing code.

How CLI arguments are handled (using clap).

Is this just referring to wrapping based on the terminal width? That is supported with the wrap_help feature though I have been considering making it a default feature.

CLI, use Clap. If you want to get fancy, use Tui.

As our CLI is getting more complex, we'll use the clap crate to parse the command line arguments.