Rocket: Configuration: How about having a fallback default configuration instead of global overrides?

[Qqwy]

_This issue might be tangentially related to prior discussion about configuration files in issue #145._

Rocket looks amazing, and it improves a lot on other web frameworks I have used. I am really eager to use it for some of my own personal projects, as well as to tell my coworkers about it. :slightly_smiling_face:

However, while reading the getting started guide, one thing surprised and confused me: The way configuration files are currently (Rocket v. 0.2.6) set up (relevant Documentation section: https://rocket.rs/guide/overview/#configuration).

Right now, a Rocket.toml file has a section per environment. It seems that these environments are hard-coded to be development, staging and production. Furthermore, there is a global section.

What I had expected would be that common settings could be stored in the global section, which could then be overridden by the environment-specific sections. However, instead, changes in the global section take precedence over the environment-specific settings.

What is the reason behind this design choice? I have frequently come across situations where many configuration settings of an application are shared across environments (especially database-related, CPU-related and external-API-related settings are shared between at least the production and staging environments), with a few (e.g. hostname, email-sending settings, logging settings) being overridden per environment.

The inverse, where I wanted to override settings that are specific to each environment by one setting in the 'global' section never arose. It seems like a weird, implicit type of behaviour where part of earlier-provided configuration settings are discarded.

So, my question: What is the reason behind the current way the 'global' configuration environment section works? Is it too late to invert the way this works?

_(A backwards-compatible solution would be to have a 'defaults' section that contains configuration settings that take the least precedence, which are then overridden by each of the environment-specific sections, which might then be overridden by an 'overrides' section, with 'global' being a deprecated alias for 'overrides'.)_

[SergioBenitez]

When I was designing the configuration system, I considered having a default section just as you propose. I was worried that a default section would be confusing: Rocket _already_ provides defaults. What would it mean to provide _different_ defaults? Is it obvious that defaults in a file are going to override Rocket's defaults?

Because I felt uncomfortable with these questions, and because defaults are usually used to provide the same values to all environments, I reasoned that a global section was a good compromise. Hence came about the global section of today.

I find the value in a default section for the same reasons you mention above. Unfortunately, I still feel uneasy about the original questions. If there was a way to resolve these questions _and_ have a section for user-provided defaults, I would be more than happy to listen. Perhaps there is a better word for "defaults" that can be used? Or, perhaps we _don't_ say that Rocket provides defaults, and instead, call those "fallbacks" or something similar, potentially removing the confusion between the "two defaults".

There are plenty more versions to go before Rocket 1.0 is ready, so there is plenty of time to make changes. I want Rocket to be as intuitive, usable, friendly, and inviting as possible. Configuration is important, and we should aim to make it all of these things and more.

[Qqwy]

The thing is that (at least right now; this is of course something that could also be changed) Rocket's configuration .toml file is also advertised as the place to put application-specific configuration settings, which are obviously things that Rocket itself cannot provide built-in defaults for.

I believe that it makes the most sense for a configuration setup to be cascading (yes, exactly in the way that CSS stylesheets are also cascading; and in this case there are also default settings that happen if you do not specify your own styling on certain types of elements), and that this follows the principle of the least surprise. Of course, advocating for/against something having/breaking 'the principle of the least surprise' is something that needs to be taken with a grain of salt, since what is surprising and what is not is very person-specific. I would greatly value other people pitching in and sharing their opinions about this, to find out if others share this opinion.

Another approach would be to have Rocket not contain internal defaults that are used when they are not in the Rocket.toml file, but instead require that a Rocket.toml is created that contains values for the settings that Rocket needs. In that way, it is even more explicit what is going on. Rocket could complain, e.g. at compile-time, that certain required settings are not filled in, and share sensible default values for the missing settings that the user could put in the Rocket.toml in the compiler error message. This would also be a great way to handle upgrading Rocket versions where new configuration settings are added.

So setting up a new app would then be:

1) cargo new myproject; cd myproject
2) add rocket to the Cargo.toml
3) cargo run (or cargo build). Rocket now lists all settings that are missing and should be added to the Rocket.toml file.
4) User is able to copy these settings from the compilation output and paste it in the Rocket.toml file.
5) User is able to configure settings to their liking, as user is aware of what values are used.
6) User runs cargo run or cargo build again; Rocket starts.

[SergioBenitez]

Let's track this in #145 and #852.