Proposal: Merge efforts with config-rs (config on crates.io)

[mehcode]

I admit I'm not entirely sure what exactly you're parsing (it looks like hjson but I feel something else is going on here). I'd like to help on the "just a rust struct" part, however.

If you haven't already, check out config-rs. It utilizes serde to get configuration (from wherever) into a final config struct.

If you're interested, could you explain a bit more about what your crate is intending to do and perhaps we can place it as a dependent or dependency of config-rs so we can work on the shared, common code together (such as getting values into a struct).

[Ongy]

Sure. First I should mention, that I don't actually have as much time to do this, as I sunk into it, so development will probably be rather slow. And one of the reasons to not just use config-rs was that I wanted to try

• What I'm parsing: Someting custom. I think it's a subset of json5, but if I had to describe it, I'd call it a leaner version of rust. I'm not trying to parse some general purpose description language, but every config will generate its own simple (pseudo context-free) language.

• config-rs: I have seen it. As I said, part of the reason I didn't use it, is that I wanted to try things out. To my understanding config-rs first reads a general language (toml/json/yaml) into an in memory representation of that language and then converts that into the target struct. I explicitly don't want to do that (in this project).

• My plans The goal is to have a parser for a (pseudo context-free) language based on the rust type. My intentions with that (what I hope to have over config-rs):

  • A stricter parser that verifies the config to some extend
  • Local error messages (I'm planing for line + char offset for my errors)
  • Conversion errors as parsing errors Expected downsides:
  • I expect it to be easier to be backward/forward compatible with config-rs
  • The languages supported by config-rs have existing linters/highlighters.
  • Probably more flexible around conversions

I think there are similar goals between config-rs and this project, but the approaches differ in significant ways.

I'd be happy about any code sharing that's possible. I don't mind relicensing for better cooperation either, I simpy default to LGPL.

[mehcode]

So a parser that's generated based on the structural type of your configuration? Interesting approach. I would probably recommend to use serde instead of custom derives and implement the parser generator as a serde::Deserializer. You'd get a ton of stuff for free (like validator that I mention below).

A stricter parser that verifies the config to some extend

Would you mind elaborating here? I'm curious how much stricter (and what you could additionally validate as opposed to what) you could get from, say, serde-json deserializing into a struct.

A plain serde-json approach checks primitive and structural types. It doesn't validate (eg. check for min, max, or perhaps that a string is an email) but validator is brilliant for that (if that's what you mean by validate).

Local error messages (I'm planing for line + char offset for my errors) Conversion errors as parsing errors

config-rs does both of these things now (not sure when you looked at config-rs as it didn't originally). It wasn't a fundamental limitation, merely a misapplication of serde.

---

Feel free to completely ignore my suggestions or opinions of your project. It's your project and spiking a radical way to define configuration is totally worthwhile.

My goal is just to get more people that are interested in working on configuration in Rust talking together. If you want to chat about anything, hit us up on #config.

[Ongy]

I looked at config-rs when I was doing a quick research into rust config libraries. so probably 3 weeks ago? I didn't see the validator back then. That looks quite nice. And yes, that's part of what I'm thinking of. I don't think that I can do any new validation, or be any stricter than I could be with existing tools, but I want to pull them into the parser.

To my understanding, if I was going over json for something like: enum Enum { Con1, Con2 } The way to go would be to read that as string for json and then go into a struct from those strings. So "Con3" would first be accepted as valid json, and the converting at a later time would then produce an error (going from json to Enum). For the parsers I want to derive, I get

• No String where it's not a string
• "Fail" immediatly (in/with context)

Failing immediatly will give me (hopefully) a way to create a "backtrace" kind of error message with line + column where the error occured (this may be integratable by keeping source information in the parsed json). The other thing I was planing on (with my merge mechanic) can probably be done by the validator crate aswell.

I'll have to look into the serde::Deserializer, but I would like to have !include style directives and maybe I'll come up with more things I want to try out, so I like the flexibility to play with my own ConfigProvider class. Another goal I have (which will probably trigger a rewrite of internals) is to be compile time evaluation capable once rustc supports that (mainly to support setting defaults from config snippets). So I'm a bit hesitant to depend on apis I have no control over.

---

No worries. I appreciate the input, and I'm happy to see, that some of the things I want to achieve can be done already, that gives me some confidence I'm not crazy.

I'll make sure to join, when I continue to work on. I just don't expect it to be anytime before october (or maybe I'll even put it off until CTFE is at least nightly.

[mehcode]

Failing immediatly will give me (hopefully) a way to create a "backtrace" kind of error message with line + column where the error occured (this may be integratable by keeping source information in the parsed json).

Currently we do not preserve line, column number information because the underlying parsers are not "low-level" enough (they don't expose line/column when a value is parsed successfully). yaml-rust is the only crate that supports this but I haven't updated my usage to use it.

My goal is for config-rs to support perfect error messages. It's certainly possible with cooperation from format parsing.