What is missing before this is a version 1.0.0 release?

[CaliViking]

I see a lot of Rust Crates being stuck in the 0.X release cycle.

What is missing before it can be declared a version 1.0.0?

Do you need community help to complete it?

Just a question.

[deg4uss3r]

Valid question @CaliViking, I think this crate is just about ready for 1.0.0 status especially now with the updated test suite.

I would like to ensure we're hitting all of the formats people expect as well before we call this library 1.0.0 and so far it seems so.

[RampedIndent]

Would a good way to update config files to a newer version be within the scope of the project?

Currently if a new field is added into a config struct, when an out of date config file is loaded it ends up with
bad data
missing field

i was thinking when it goes to load the config file

try load config
if error "missing field"
    check if default.config_version > file.config_version
        add missing fields to config file
        save config file
        load config 
        break
else
    Error("Invalid config file missing field")

Been messing around in a fork to see how to go about implementing such a feature.

[Zykino]

This sound like a big feature (what happens when there is a new field, one is removed, one change type, …).

In the same time load_path is already required to be Default.

pub fn load_path<T: Serialize + DeserializeOwned + Default>(
    path: impl AsRef<Path>,
) -> Result<T, ConfyError> {

I’m not comfortable with it but I remember it being possible to generate a default config and then combining it with another one. So it may be possible to move let cfg = T::default(); before the match and combining it with serde’s output.

[Zykino]

For the different format, Serde’s official list of supported one are here

If I remove all binaries one we have left (with my POV on them):

• JSON ( and friends HJSON / JSON5) : Read human / 5, serialize standard. Doable but will bring some questions (why my comments disapeared…). JSON itself is not really human friendly so not sure they are worth it (even if the appeal from dev is there).
• YAML: its in
• TOML: its in
• RON: its in
• URL: its almost like binary, not handy to use 😉
• S-expressions: I do not see the difference with lisp like language, it look more like code than config

For what I understand all the others are either binary format (and I could be wrong for some), or do only serialization or deserialization.

So as of today, of the 6 format more or less available, 3 are already in confy, 2 are kind of domain specific and not specifically for storing config. Rest JSON… I will let you decide its fate.

It is still possible to say "we wold love to support XXX even if there are no serde’s binding today".

Also, I am not sure adding a new data format later would grant a major version bump. I might be wrong (adding a new feature only mean minor version bump isn’t it?).

[RampedIndent]

It is still possible to say "we wold love to support XXX even if there are no serde’s binding today".

Also, I am not sure adding a new data format later would grant a major version bump. I might be wrong (adding a new feature only mean minor version bump isn’t it?).

From how the config formats are currently implemented it would be relatively easy to add a new serde supported format with no breaking changes or major code restructure. So i think it adding a new format could get away with a minor version bump.

• JSON ( and friends HJSON / JSON5) : Read human / 5, serialize standard. Doable but will bring some questions (why my comments disapeared…). JSON itself is not really human friendly so not sure they are worth it (even if the appeal from dev is there).

I've had to write json by hand before, i'd really rather never have to use it for something again. So i have to agree with this point.

[Zykino]

I just remember that zellij use the KDL format. The kaydle crate implements it with serde, but other crates exist too.

In short, it looks like a mix between JSON and XML. From the website:

author "Alex Monad" email="[email protected]" active=true

contents {
  section "First section" {
    paragraph "This is the first paragraph"
    paragraph "This is the second paragraph"
  }
}

This may be a good format to add if it take off… Or other format will come to life at some point anyways so expect to add new format (only the popular ones?) with time.