Rocket's handling of config file can be redundant for many applications about rocket

[SergioBenitez]

Can you elaborate on something you want to do that's cumbersome to do with the current design? Config is a very small structure with a very simple API, so I can't imagine anything that would be too cumbersome.

[jkelin]

As I said, redundant (as in not needed, needlessly complicating api for me). I want to make single exe application that you can drop in anywhere and run it, no configuration needed. When you want configuration, you pass it as arguments from the command line. Having a config file is really not an option for me. I can still make custom Config by calling Config::default_for but that requires filepath, which I don't have or need.

More generally, it would be really good if you would not force configuration file and specific configuration format on everyone, as that seems to be in contradiction with https://rocket.rs/guide/introduction/#foreword point 3.

[SergioBenitez]

I think this is a blunder with the API, and one that I was aware of but didn't change prior to releasing. You don't need to have a file for the configuration, you just need to give the default_for method a path, even if the file it refers to doesn't exist. Rocket itself does this by using the CWD plus a default config name. The path is required because Rocket needs to determine where paths in the config file are relative to, and it uses the configuration file path passed to this function to determine it. This is really strange, and the API needs to be changed to allow a file-path-less config.

With this change, would you still feel Rocket is forcing a decision on you? The configuration structure is small, and any trait to make the configuration structure generic will require more work to implement than building a Config structure from defaults.

[jkelin]

Yes, file-path-less config sounds good enough. I would still suggest trait based api because I think it would be much easier to maintain/extend in the future.
I like the concept of configuration environment defaults (dev/staging/production), but to some even they may seem redundant.

I would suggest adding new function without any arguments (it can initialize Config like Environment::Production would) and a second 'constructor' (maybe default_with) which would take Environment as an argument.

[SergioBenitez]

Resolved in fb24ee3.