feat: read config toml file

[1garo]

This PR idea is to read rio's configuration file (written in .toml), parse it and returns Config struct

// initial idea for Config
pub struct Config {
    performance: Performances,
    width: Option<u16>,
    height: Option<u16>,
}

• read toml file
• parse toml file
• get path based on OS
• more configs???

[raphamorim]

Hey @1garo , is okay to use serde 👍 Keep the good work! 🚀

[raphamorim]

Believe is better have as u16 instead of Option. To avoid additional unwrap when using the configuration struct later. Since all properties should have a default we can unwrap it on the new.

Also will be good to have a default in the impl. E.g: https://doc.rust-lang.org/std/default/trait.Default.html

[1garo]

I have started the implementation here

I couldn't come with a solution for when the user have the config file, but didn't pass one of the parameters.

Because if I set the struct as below:

struct Config {
    performance: Option<Performance>,
    width: u16,
    height: u16,
}

Now the problem is that when we parse, as the user did not specified performance, it is None,

Config {
    performance: None,
    width: 300,
    height: 200,
}

Did you have something in mind?

obs: the code can be not that rusty, still learning some patterns, if you think something can improve, just let me know

[raphamorim]

No worries at all @1garo, you are doing a great job. Usually when you're wrapping and come as None, you can use unwrap_or_else(|| to return the default. Let me know if you still have questions, we can book a day and do this part together 👍

[1garo]

sounds great, if you can talk today or tomorrow, just say where I can reach out to you!

[raphamorim]

If you have telegram, just drop me a message on same username as GH. I also have discord just in case.

[1garo]

I think discord is easier for me, I used telegram once in my life. 1garo#7086

[1garo]

I feel that create the file to test is not the best way tho, I was thinking in load receive a &str with the path name or a buffer, but then would be bad for the usage, as we wan't the user just to Config::load(), tell me what you think.

[raphamorim]

I feel that create the file to test is not the best way tho, I was thinking in load receive a &str with the path name or a buffer, but then would be bad for the usage, as we wan't the user just to Config::new(), tell me what you think.

For me both works, you can also write a helper function on tests to write a configuration file in memory and returns the file path. For example:

fn create_temporary_config(width: u16, height: u16) -> std::ffi::OsString {
   // create config in memory by serializing data
   // save on a /tmp/test-config.toml or any other place
   // feel free to implement the write however you want to 🚀 
   
   Config::load_from_path(filepath) // load_from_path should just call load() with a custom path 
}

Could be useful: https://stackoverflow.com/questions/71371861/how-do-i-write-an-array-of-homogenous-structs-in-rust-to-a-file-that-i-can-fread , https://betterprogramming.pub/reading-and-writing-a-file-in-rust-47d2bc7086ac