In D8978#265459, @michal wrote:

This and the next diffs seem a bit complicated for the email configuration.

Agree, I have this feeling too

1. Moving the "token replacement from env", from FromStr to the parse method introduces later in the stack. I don't I have ever seen a non-pure from_str so that feels weird to me

This is doable I think

2. Instead of having a #[clap(ignore)] OnceCell, add a email config to the reports service (probably as an Option<>), and just fill it once during init

This one is more tricky when it comes to encapsulation - In current configuration, temporary values (raw CLI args etc) and parse functions are only accessible inside config modules. When I moved config init to the service, these temporary values would have to be accessible there (and therefore across the whole app) which I was trying to avoid.
Perhaps having a custom clap parser (or other kind of extension) would better fit here but I couldn't figure it out quickly and didn't want to spend more time on this. I can create a follow-up if you feel strongly

Would something like this work?

// Config files

pub struct AppConfig {
 <...>

 #[command(flatten)]
 email_args: EmailArgs // `EmailArgs` is the same as in the next diff
}

impl AppConfig {
 <...>
 
 /// Note: this can potentially read from file system
 /// so you should cache it
 pub fn load_email_config(&self) -> Option<EmailConfig> {
   // Basically the `EmailArgs::parse` method + env var handling form `FromStr`
 }

 // Remove `emails_enabled()` 
}

// Service init files

pub struct ReportsService {
  <...>

  email_config: Option<EmailConfig>,
}

// in http server init
let service = ReportsService::new(db, blob_client, cfg.load_email_config());

I think it fits the encapsulation requirements? If you like it or some parts of it you can update the diff, if not we can leave it as-is (I don't think we need to make a followup task in this case).