dry-system settings provider source: custom environment variable prefix?

We are currently evaluating dry-system’s settings provider source, to see if it can replace our in-house environment loader in all of our repos. We’re using dry-system already to boot dependencies, so it would be super nice to make use of it for environment variable loading too! :slight_smile:

However, it doesn’t seem to be possible to assign a prefix to an environment variable name without also having the prefix in the internal setting name. I took a look at the source and it is doing this:

settings.to_a.each do |setting_name|
  value = loader[setting_name.to_s.upcase]

  begin
    settings_obj.config.public_send(:"#{setting_name}=", value) if value

So it looks like the environment variable name is hardcoded to be the uppercase version of the settings name.

We would absolutely love it if it were possible to customise this transformation without having to define our own settings provider (this would require us to maintain our own environment loader code which is exactly what we’re trying to avoid!).

At the least, the ability to add a prefix to the environment variable would satisfy our use case. This is important for us in development where we often have multiple apps running simultaneously on the same host using a shared .env file.

Alternatively, the ability to provide an optional block that defines an arbitrary settings name → environment variable transformation could be a particularly neat way of achieving this.

For our use case, customising the environment variable name per provider (rather than per setting) would be sufficient (and simpler to implement).

We’d be totally happy to write up a PR if maintainers think it’s a useful addition! If we can get this over the line then we will feel much more comfortable making the switch.

Hey yeah I think it would be great if this was configurable. Having ability to have nested keys from env would be great too like STRIPE__API_KEY would be turned into settings.stripe.api_key.

I’d be happy to see a PR that adds this. @timriley would you be OK with a feature like that?