Strongly typed YAML library for Rust

Overview

Serde YAML

github crates.io docs.rs build status

This crate is a Rust library for using the Serde serialization framework with data in YAML file format.

This library does not reimplement a YAML parser; it uses yaml-rust which is a pure Rust YAML 1.2 implementation.

Dependency

[dependencies]
serde = "1.0"
serde_yaml = "0.8"

Release notes are available under GitHub releases.

Using Serde YAML

API documentation is available in rustdoc form but the general idea is:

use std::collections::BTreeMap;

fn main() -> Result<(), serde_yaml::Error> {
    // You have some type.
    let mut map = BTreeMap::new();
    map.insert("x".to_string(), 1.0);
    map.insert("y".to_string(), 2.0);

    // Serialize it to a YAML string.
    let s = serde_yaml::to_string(&map)?;
    assert_eq!(s, "---\nx: 1.0\ny: 2.0\n");

    // Deserialize it back to a Rust type.
    let deserialized_map: BTreeMap<String, f64> = serde_yaml::from_str(&s)?;
    assert_eq!(map, deserialized_map);
    Ok(())
}

It can also be used with Serde's derive macros to handle structs and enums defined by your program.

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_yaml = "0.8"
use serde::{Serialize, Deserialize};

#[derive(Debug, PartialEq, Serialize, Deserialize)]
struct Point {
    x: f64,
    y: f64,
}

fn main() -> Result<(), serde_yaml::Error> {
    let point = Point { x: 1.0, y: 2.0 };

    let s = serde_yaml::to_string(&point)?;
    assert_eq!(s, "---\nx: 1.0\ny: 2.0");

    let deserialized_point: Point = serde_yaml::from_str(&s)?;
    assert_eq!(point, deserialized_point);
    Ok(())
}

License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Comments
  • Expose the Serializer and Deserializer types

    Expose the Serializer and Deserializer types

    This is required for composition with other libraries like serde_ignored.

    This is harder than just slapping pub on the thing because the Deserializer currently borrows some data owned by the serde_yaml::from_str method:

    struct Deserializer<'a> {
        events: &'a [(Event, Marker)],
        /// Map from alias id to index in events.
        aliases: &'a BTreeMap<usize, usize>,
        pos: &'a mut usize,
        path: Path<'a>,
    }
    

    May need to refactor into a public owned Deserializer and an internal borrowed Deserializer.

    The Serializer is also hard because it doesn't write to an underlying io::Write like JSON's serializer does.

    enhancement 
    opened by dtolnay 11
  • How to opt out of !Tag syntax for enums in 0.9.0+?

    How to opt out of !Tag syntax for enums in 0.9.0+?

    Hi, I was wondering if there is a way (besides just not upgrading the crate version) to opt out of the !Tag syntax for enums and keep the old behaviour?

    opened by willfindlay 10
  • Allow users to get error locations

    Allow users to get error locations

    Simple change to make ErrorImpl public.

    I'd like to be able to use the Marker Information from the scanner error to provide users that are changing files the ability to check to see whether their yaml is valid and, if not, where the issue lies. To do this i need the Marker information from the ScannerError in a structured format, so I can feed that into an editor.

    This resolves https://github.com/dtolnay/serde-yaml/issues/78

    I also have a PR out about getting access to the Marker for Scanner errors, which is also not public.

    opened by cetra3 9
  • Out of bounds access in output generated by PyYAML

    Out of bounds access in output generated by PyYAML

    Moved from https://github.com/dtolnay/serde-yaml/issues/49#issuecomment-304899926.


    Hi, I ran into the Out of bounds access in the wild with some output generated by PyYAML. I minimized it to a pretty simple example:

    ---
    content: "Foo\
        Bar"
    

    Is this just a case of missing support for line continuations? Should I file a separate ticket for that?


    @radix

    opened by dtolnay 9
  • u128 integers >= 64 bits serialize as floats

    u128 integers >= 64 bits serialize as floats

    The newly released 0.8.6 includes u128 support. However, values of 2^64 or larger serialize as floats instead of integers, as shown by this test case.

    #[test]
    fn test_u128_big() {
        let thing: u128 = 18446744073709551616;   // 2^64
        let yaml = unindent(
            "
            ---
            18446744073709551616",
        );
        test_serde(&thing, &yaml);
    }
    
    ---- test_u128_big stdout ----
    thread 'test_u128_big' panicked at 'assertion failed: `(left == right)`
      left: `"---\n18446744073709551616"`,
     right: `"---\n18446744073709553000.0"`', tests/test_serde.rs:40:5
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    

    The i128 branch in my fork of this repo does not exhibit the same bug at revision d79d55e.

    opened by asomers 8
  • Empty field deserializes to string as

    Empty field deserializes to string as "~"

    In the following example, both inputs deserialize to field: "~". I would expect the first one to deserialize to field: "".

    #[macro_use]
    extern crate serde_derive;
    
    extern crate serde;
    extern crate serde_yaml;
    
    #[derive(Deserialize, Debug)]
    struct S {
        field: String,
    }
    
    fn main() {
        println!("{:?}", serde_yaml::from_str::<S>("field:"));
        println!("{:?}", serde_yaml::from_str::<S>("field: ~"));
    }
    
    bug 
    opened by dtolnay 8
  • serde_yaml::Hash unusable if floats are present in map _value_ positions.

    serde_yaml::Hash unusable if floats are present in map _value_ positions.

    These two maps, when turned to serde_yaml::Value give the same hashes:

    foo: 1.2
    
    foo: 8.7
    

    The reason is the Hash instance of Number:

    #[allow(clippy::derive_hash_xor_eq)]
    impl Hash for Number {
        fn hash<H: Hasher>(&self, state: &mut H) {
            match self.n {
                N::Float(_) => {
                    // you should feel bad for using f64 as a map key
                    3.hash(state)
                }
                N::PosInt(u) => u.hash(state),
                N::NegInt(i) => i.hash(state),
            }
        }
    }
    

    It gives constant values for f64. The comment tries to shame the user about using floats as keys. Sadly, it completely forgets that Number can be used elsewhere. In this case, we have:

    #[derive(Clone, Debug, Default, Eq, Hash, PartialEq, PartialOrd)]
    pub struct Mapping {
        map: LinkedHashMap<Value, Value>,
    }
    

    The Hash for the LinkedHashMap just hashes the (key, value) values.

    This means that when value is N::Float, the hash doesn't change when the value does. This makes it pretty much unfit for purpose...

    opened by Fuuzetsu 7
  • Support serialization of strings to literal and folded scalars

    Support serialization of strings to literal and folded scalars

    Apologies if this feature already exists, but I didn't see it in the documentation.

    Info

    the literal scalar | can be used in YAML to break up a string to multiple lines, treating the line breaks literally.

    the folded scalar > also can be used to break up a string into multiple lines, but it treats line breaks as spaces.

    Request

    When serializing a value containing a multiline string, it seems to always serialize that string to a single line with line breaks represented as \n (reproduction) I think that there should be some way to specify how you want your string to be serialized (single line, folded scalar, literal scalar).

    Scalar Examples

    Literal: |

    Input

    key: |
      line 1
      line 2
    

    Output (JSON)

    { "key": "line 1\nline 2\n" }
    

    Folded: >

    Input

    key: >
      word1
      word2
    

    Output (JSON)

    { "key": "word1 word2" }
    
    opened by spenserblack 7
  • 128-bit integer support

    128-bit integer support

    i128 and u128 can now be serialized and deserialized. Support is conditionalized on the disabled-by-default i128 feature flag, and requires rustc 1.26.0 or later. The minimum required version of Serde is now 1.0.60.

    opened by asomers 7
  • Deserialize empty file to struct containing no required fields

    Deserialize empty file to struct containing no required fields

    ... even though there are no non-optional fields in the struct. Or any fields at all, for that matter.

    Attempting to deserialize an empty file (or a file containing only newlines) produces the following error:

    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: EndOfStream', /checkout/src/libcore/result.rs:916:4
    

    IMO deserializing an empty file should succeed as long as there are no required fields in the struct.

    (I'm using serde_yaml 0.7.3)

    bug 
    opened by forbjok 6
  • Allow direct inspection of a Tag.

    Allow direct inspection of a Tag.

    This PR makes it possible to directly inspect a tag as a string slice.

    For my use case, I want to do some more advanced inspection than only testing for equality.

    To avoid surprising behavior with the potential presence of an exclamation mark, the function is called as_str_stripped() and documents that it strips the leading exclamation mark if it is present.

    opened by de-vri-es 5
  • [Bug] Newtype enum variant deserialization failure when used with `#[serde(flatten)]`

    [Bug] Newtype enum variant deserialization failure when used with `#[serde(flatten)]`

    TL;DR

    If you create an enum that contains a newtype variant, wrap the enum in a struct, wrap the said struct in another struct and use #[serde(flatten)] on it, the struct can no longer successfully deserialize (while serialization is unaffected).

    Deserialization fails with message: untagged and internally tagged enums do not support enum input.


    That's not a very helpful description so here's a MRE:

    use serde::{Deserialize, Serialize};
    
    fn main() {
        // this works
        let gender = Gender::Other("F22".into());
        assert_eq!(
            &gender,
            &serde_yaml::from_str(&dbg!(serde_yaml::to_string(&gender).unwrap())).unwrap()
        );
    
        // this still works
        let info = Info { gender };
        assert_eq!(
            &info,
            &serde_yaml::from_str(&dbg!(serde_yaml::to_string(&info).unwrap())).unwrap()
        );
    
        // this errors
        let user = User { info };
        assert_eq!(
            &user,
            &serde_yaml::from_str(&dbg!(serde_yaml::to_string(&user).unwrap())).unwrap()
        );
    }
    
    #[derive(Clone, Debug, Eq, PartialEq, Deserialize, Serialize)]
    enum Gender {
        Female,
        Male,
        Other(String),
    }
    
    #[derive(Clone, Debug, Eq, PartialEq, Deserialize, Serialize)]
    struct Info {
        gender: Gender,
    }
    
    #[derive(Clone, Debug, Eq, PartialEq, Deserialize, Serialize)]
    struct User {
        #[serde(flatten)]
        info: Info,
    }
    

    Misc

    I tried the exact same example using serde_json, no errors. So I think this is a serde_yaml issue rather than a serde issue.

    A quick search did find this issue though, not sure if it's related: https://github.com/ron-rs/ron/issues/217.

    Versions

    • OS: Linux 6.0.8 x86_64
    • rust: 1.65.0 (stable-x86_64-unknown-linux-gnu)
    • serde: 1.0.147
    • serde_yaml: 0.9.14
    opened by cyqsimon 1
  • Allow the indentation character to be customized

    Allow the indentation character to be customized

    Hello, I'm working on a feature where we inherit settings from .editorconfig to determine the pretty formatting options when writing JSON/YAML. Here's an example of this working here: https://github.com/moonrepo/moon/pull/446/files#diff-eecbfd85b3348b94eb93e82dc28debcfbaca9a8e9664c43635a8ce5eecf613e9R97

    This is super easy with serde_json, as we can simply use this: https://docs.rs/serde_json/latest/serde_json/ser/struct.PrettyFormatter.html#method.with_indent

    However, with serde_yaml, there doesn't seem to be a way to change the pretty settings, or indentation. I briefly dug into the source code, but this looks to be abstracted away via the libyaml crate? Regardless, it would be nice if custom indentation would be supported, both spaces and tabs.

    Cheers!

    opened by milesj 0
  • Yaml output indentation

    Yaml output indentation

    I am using https://github.com/juhaku/utoipa 's to_yaml which uses serde_yaml::to_string, to generate a openapi 3 yaml file, and there is a lack of typical indentation in the output of arrays/sequences.

    e.g.

    openapi: 3.0.3
    info:
      title: foobar
      description: Service to do blah ...
      contact:
        name: ''
      license:
        name: ''
      version: 0.1.0
    paths:
      /my_endpoint_name:
        post:
          tags:
          - my_tag
    

    Typical linters, e.g. https://pypi.org/project/yamllint/, require the - my_tag to be indented an extra two spaces. A lot of python cloud tools use yamllint, e.g. ansible-lint. More can be seen at https://www.wheelodex.org/projects/yamllint/rdepends/ , and that is just Python. https://developers.home-assistant.io/docs/documenting/yaml-style-guide/ is another style guide which expects that indentation.

    I did a quick test against serde_yaml directly, and it looks like that the lack of indentation is the default. i.e. the following is true

    let mut buffer = Vec::new();
    let mut ser = serde_yaml::Serializer::new(&mut buffer);
    let deserialized: BTreeMap<&str, Vec<&str>> = serde_yaml::from_str("k:\n  - a\n  - b\n  - c\n").unwrap();
    deserialized.serialize(&mut ser).unwrap();
    assert_eq!(buffer, b"k:\n- a\n- b\n- c\n");
    

    i.e. the indentation is dropped.

    It would be great if the default could be updated. And allow something like serde_json::PrettyFormatter::with_indent. It would also be handy to be able to specify other defaults, like whether strings should be enclosed in ' or " by default. I see something similar was asked in https://github.com/dtolnay/serde-yaml/issues/226

    opened by jayvdb 6
  • help parsing YAML with keys as with hyphens

    help parsing YAML with keys as with hyphens

    Greetings,

    I have YAML files such as:

    foo-bar: baz

    I'd like to use serde-yaml to parse into:

    struct FooBar {
        foo_bar: String,
    }
    

    Do you know if there is some simple/elegant way to deserialize this mismatch between hyphens and underscores?

    Thanks for the help!

    -m

    opened by mzagrabe 1
  • Minified YAML?

    Minified YAML?

    Thanks for reading this, and making serde-yaml.

    I wonder if there is a way to create minified YAML output using this? https://onlineyamltools.com/minify-yaml

    opened by cameronelliott 0
  • Preserve double quotes around

    Preserve double quotes around "yes" and "no" strings

    I am having an issue with preserving string values of "yes" and "no" after converting from str -> yaml value -> (string/str). "yes" is not the same as yes (YAML version 1.1 interprets the latter as bool). Is there a setting or flag I can set to preserve the double quotes around strings yes and no, so they do not get interpreted as bools?

    let _str = r#"
    QuoteYes: "yes"
    QuoteNo: "no"
    RegYes: yes
    RegNo: no
    "#;
    let to_yaml = serde_yaml::from_str::<serde_yaml::Value>(_str).unwrap();
    let to_str = serde_yaml::to_string(&to_yaml).unwrap();
    std::fs::write("./test.yaml", &to_str);
    

    expected output file:

    QuoteYes: "yes"
    QuoteNo: "no"
    RegYes: yes
    RegNo: no
    

    actual output file:

    QuoteYes: yes
    QuoteNo: no
    RegYes: yes
    RegNo: no
    
    opened by RandomGHUser 1
Releases(0.9.16)
  • 0.9.16(Dec 19, 2022)

  • 0.9.15(Dec 17, 2022)

  • 0.9.14(Oct 21, 2022)

  • 0.9.13(Sep 14, 2022)

  • 0.9.12(Sep 14, 2022)

  • 0.9.11(Sep 2, 2022)

  • 0.9.10(Aug 21, 2022)

  • 0.9.8(Aug 13, 2022)

  • 0.9.7(Aug 13, 2022)

  • 0.9.6(Aug 13, 2022)

  • 0.9.5(Aug 13, 2022)

  • 0.9.4(Aug 3, 2022)

    • Add serde_yaml::with::singleton_map for serialization of enums as a 1-entry map (#300)
    • Reject duplicate keys when deserializing Mapping or Value (#301)
    Source code(tar.gz)
    Source code(zip)
  • 0.9.3(Aug 2, 2022)

  • 0.9.2(Jul 30, 2022)

  • 0.9.1(Jul 29, 2022)

    • Fix panic on some documents containing syntax error (#293)
    • Improve error messages that used to contain duplicative line/column information (#294)
    Source code(tar.gz)
    Source code(zip)
  • 0.9.0(Jul 28, 2022)

    API documentation: https://docs.rs/serde_yaml/0.9

    Highlights

    • The serde_yaml::Value enum gains a Tagged variant which represents the deserialization of YAML's !Tag syntax. Tagged scalars, sequences, and mappings are all supported.

    • An empty YAML input (or document containing only comments) will deserialize successfully to an empty map, empty sequence, or Serde struct as long as the struct has only optional fields. Previously this would error.

    • A new .apply_merge() method on Value implements YAML's << merge key convention.

    • The Debug representation of serde_yaml::Value has gotten vastly better (https://github.com/dtolnay/serde-yaml/pull/287).

    • Deserialization of borrowed strings now works.

      #[derive(Deserialize, Debug)]
      struct Struct<'a> {
          borrowed: &'a str,
      }
      
      let yaml = "borrowed: 'kölcsönzött'\n";
      let value: Struct = serde_yaml::from_str(yaml)?;
      println!("{:#?}", value);
      
    • Value's and Mapping's methods get and get_mut have been generalized to support a &str argument, as opposed to requiring you to allocate and construct a Value::String for indexing into another existing Value.

    • Mapping exposes more APIs that have become conventional on map data structures, such as .keys(), .values(), .into_keys(), .into_values(), .values_mut(), and .retain(|k, v| …).

    Breaking changes

    • Serialization no longer produces leading ---\n on the serialized output. You can prepend this yourself if your use case demands it.

    • Serialization of enum variants is now based on YAML's !Tag syntax, rather than JSON-style singleton maps.

      #[derive(Serialize, Deserialize)]
      enum Enum {
          Newtype(usize),
          Tuple(usize, usize, usize),
          Struct { x: f64, y: f64 },
      }
      
      - !Newtype 1
      - !Tuple [0, 0, 0]
      - !Struct {x: 1.0, y: 2.0}
      
    • A bunch of non-base-10 edge cases in number parsing have been resolved. For example 0x+1 and ++0x1 are now parsed as strings, whereas they used to be incorrectly treated as numbers.

    • Deserializers obtained through iteration can no longer be iterated further:

      let deserializer = serde_yaml::Deserializer::from_str(multiple_documents);
      for de in deserializer {
          // correct:
          let myvalue = T::deserialize(de)?;
      
          // incorrect: used to produce some questionable result, now produces 0 sub-documents
          for questionable in de {
              let wat = T::deserialize(questionable)?;
          }
      }
      
    • The abandoned yaml-rust crate is no longer used as the YAML backend. The new libyaml-based backend surely has different edge cases and quirks than yaml-rust.

    • Some excessive PartialEq impls have been eliminated.

    • The serde_yaml::to_vec function has been removed. Use serde_yaml::to_writer for doing I/O, or use serde_yaml::to_string + .into_bytes() on the resulting String.

    • The serde_yaml::seed module has been removed. Now that a serde_yaml::Deserializer is publicly available, the same use cases can be addressed via seed.deserialize(Deserializer::from_str(…)) instead.

    Bugfixes

    • Empty values in a mapping are supported, and deserialize to empty string when the corresponding struct field is of type string. Previously they would deserialize to "~" which makes no sense.

    • 128-bit integer deserialization now supports hex and octal input.

    • Serde_yaml now includes a mitigation against a "billion laughs" attack in which malicious input involving YAML anchors and aliases is used to consume an amount of processing or memory that is exponential in the size of the input document. Serde_yaml will quickly produce an error in this situation instead.

    Source code(tar.gz)
    Source code(zip)
  • 0.8.26(Jul 16, 2022)

  • 0.8.25(Jul 8, 2022)

  • 0.8.24(May 3, 2022)

  • 0.8.23(Dec 13, 2021)

  • 0.8.22(Dec 13, 2021)

  • 0.8.21(Sep 10, 2021)

  • 0.8.20(Aug 26, 2021)

  • 0.8.19(Aug 22, 2021)

  • 0.8.18(Aug 18, 2021)

  • 0.8.17(Feb 10, 2021)

  • 0.8.16(Feb 2, 2021)

    • Add a Serializer and Deserializer type (#185, #186)

      let mut buffer = Vec::new();
      let mut ser = serde_yaml::Serializer::new(&mut buffer);
      
      let mut object = BTreeMap::new();
      object.insert("k", 107);
      object.serialize(&mut ser)?;
      
      let de = serde_yaml::Deserializer::from_slice(&buffer);
      let value = Value::deserialize(de)?;
      println!("{:?}", value);
      
    • Support multi-doc serialization (#187)

      let mut buffer = Vec::new();
      let mut ser = serde_yaml::Serializer::new(&mut buffer);
      
      let mut object = BTreeMap::new();
      object.insert("k", 107);
      object.serialize(&mut ser)?;
      
      object.insert("j", 106);
      object.serialize(&mut ser)?;
      
      assert_eq!(buffer, b"---\nk: 107\n...\n---\nj: 106\nk: 107\n");
      
    • Support multi-doc deserialization (#189)

      let input = "---\nk: 107\n...\n---\nj: 106\n";
      
      for document in serde_yaml::Deserializer::from_str(input) {
          let value = Value::deserialize(document)?;
          println!("{:?}", value);
      }
      
    Source code(tar.gz)
    Source code(zip)
  • 0.8.15(Jan 5, 2021)

  • 0.8.14(Oct 31, 2020)

Owner
David Tolnay
David Tolnay
LibYAML bindings for Rust

libyaml-rust LibYAML bindings for Rust Dependencies LibYAML 0.1.4 or higher Stable Rust (2015/2018 edition) Usage Parse from memory extern crate yaml;

김현강 22 Aug 3, 2022
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

null 294 Dec 23, 2022
Strongly typed JSON library for Rust

Serde JSON   Serde is a framework for serializing and deserializing Rust data structures efficiently and generically. [dependencies] serde_json = "1.0

null 3.6k Jan 5, 2023
Extensible, strongly-typed Rust OAuth2 client library

OAuth2 An extensible, strongly-typed implementation of OAuth2 (RFC 6749). Documentation is available on docs.rs. Release notes are available on GitHub

David Ramos 602 Dec 25, 2022
Strongly typed Gura library for Rust

Serde Gura This crate is a Rust library for using the Serde serialization framework with data in Gura file format. This library does not re-implement

Gura Config Lang 12 Nov 14, 2022
A Rust library for interacting with OpenAI's ChatGPT API, providing an easy-to-use interface and strongly typed structures.

ChatGPT Rust Library A Rust library for interacting with OpenAI's ChatGPT API. This library simplifies the process of making requests to the ChatGPT A

Arend-Jan 6 Mar 23, 2023
Strongly typed routes for Rust

routetype This repository is a work in progress, experimental exploration of strongly typed routing in Rust. It follows my previous work with Yesod in

Michael Snoyman 32 Jul 22, 2022
Strongly typed Elasticsearch DSL written in Rust

Strongly typed Elasticsearch DSL written in Rust This is an unofficial library and doesn't yet support all the DSL, it's still work in progress. Featu

null 173 Jan 6, 2023
Lightweight, Strongly Typed Xata Client written in Rust

xata-rs: Lightweight, Strongly Typed Xata Client xata-rs is a third party Xata client, allowing interaction with Xata's REST API. Adding xata-rs (WIP)

Alvaro Machuca Recalde 4 Jun 12, 2023
Orion lang is a lispy programming language that is strongly and statically typed.

Orion Orion is a lisp inspired statically typed programming language written in Rust Install To install orion you can either: Download binary from the

Wafelack 226 Dec 17, 2022
Improve and strengthen your strings by making them strongly-typed with less boilerplate

aliri_braid Improve and strengthen your strings Strongly-typed APIs reduce errors and confusion over passing around un-typed strings.

Marcus Griep 27 Dec 29, 2022
RefineDB - A strongly-typed document database that runs on any transactional key-value store.

RefineDB - A strongly-typed document database that runs on any transactional key-value store.

Heyang Zhou 375 Jan 4, 2023
beat saber is a strongly typed, self-documenting and highly performant programming language

beatsaber beat saber is a strongly typed, self-documenting and highly performant programming language. With beat saber we aimed to create a language t

Untitled 4 Jan 17, 2022
Make your IDs strongly typed!!

About TypedId introduces a single type, aptly named TypedId. This is a generic wrapper any type, often types that you would use as an identifier. Howe

Tyler Bloom 8 Sep 2, 2022
Strongly typed, extensible event mediator.

mediatrix Strongly typed, extensible event mediator. For more info and explanation, please see the docs. Usage Sync use mediatrix::synchronous::basic:

nyvs 2 Nov 14, 2022
Rust I18n is use Rust codegen for load YAML file storage translations on compile time, and give you a t! macro for simply get translation texts.

Rust I18n Rust I18n is use Rust codegen for load YAML file storage translations on compile time, and give you a t! macro for simply get translation te

Longbridge 73 Dec 27, 2022
A pure rust YAML implementation.

yaml-rust The missing YAML 1.2 implementation for Rust. yaml-rust is a pure Rust YAML 1.2 implementation, which enjoys the memory safety property and

Chen Yuheng 543 Dec 24, 2022
PEG parser for YAML written in Rust 🦀

yaml-peg PEG parser (pest) for YAML written in Rust ?? Quick Start ⚡️ # Run cargo run -- --file example_files/test.yaml # Output { "xmas": "true",

Visarut Phusua 4 Sep 17, 2022
CLI tool to convert HOCON into valid JSON or YAML written in Rust.

{hocon:vert} CLI Tool to convert HOCON into valid JSON or YAML. Under normal circumstances this is mostly not needed because hocon configs are parsed

Mathias Oertel 23 Jan 6, 2023
A cli utility written in Rust that allows fetching all the labels of a project, save those as a YAML file

A cli utility written in Rust that allows fetching all the labels of a project, save those as a YAML file that you can easily edit or save as backup and apply a saved preset to new repositories.

Chevdor 4 May 5, 2022