Dynamically load development or test default values #266

Activity

1. shekibobo commented on Jul 3, 2017

   

   shekibobo

   on Jul 3, 2017

   More actions

   Priority of variables loaded, from lowest to highest:

   1. Defaults declared in the Envfile, i.e. string :foo, default: "Foo"
   2. Values declared in .env.yml files. Last declaration wins, overriding previous declarations of the same named variable.
   3. ENV variables declared on the system.

   With this in mind, I don't think defaults is a confusing method name. I'd suggest something that suggests the precedence of the files being loaded:

   source ".env.yml"
   source ".env.test.yml", if: -> { Rails.env.test? }
   
   load ".env.yml"
   load ".env.test.yml", if: -> { Rails.env.test? }
   
   provide ".env.yml"
   provide ".env.test.yml", if: -> { Rails.env.test? }

   defaults makes it unclear what values will actually be loaded.

   I think the strategy for loading really depends on if you expect value files to act like cascading stylesheets, where you can provide overrides in special conditions, then multiple DSL source calls makes the most sense. If you expect variables to be more mutually exclusive and independent, then I think a single YAML file with keys makes more sense. I have concerns in either situation.

   • Environment files that depend on values previously declared in another environment file seems risky and unpredictable. Cascading is tricky if you don't see how things are being sourced. I'd rather see a single file that has all the overrides declared in them so there's fewer places to check to determine where something was sourced.
   • A single env file that has keyed value sets is nice for seeing what's overridden where, but there's a good chance you might want to have overrides for one environment (test) in source control, but not from another (production). So in that case, I'd rather have separate env files for each environment I'd be loading.
   • If you're using a single keyed environment file and passing the key in the Envfile, you miss out on cascaded loading unless you combine it with subsequent conditional loading, i.e.

   source ".env.yml", key: :base
   source ".env.yml", key: :test, if: -> { Rails.env.test? }

   I guess it all depends on what your goals are, but I think separating the idea of defaults and sourced variables is important for the clarifying the ideas in this discussion.
2. laserlemon commented on Dec 27, 2017

   

   laserlemon

   on Dec 27, 2017

   Last edited by laserlemon

   OwnerAuthor

   More actions

   Update: After mulling this over some more, I'm leaning toward a single YAML configuration file with the ability to key the file according to the application environment. To define the application environment (since Figaro will no longer be Rails-dependent), I'm adding the environment method to the DSL. For example:

   # env.rb
   environment key: "APP_ENV", default: "development"
   
   defaults "env.yml"
   
   string :stripe_publishable_key
   string :stripe_secret_key
   decimal :price, default: "9.99"

   # env.yml
   stripe_publishable_key: "pk_test_NlsxCBp2TPGWyQeHUFw4uj4L"
   stripe_secret_key: "sk_test_iHBheVvfdegliMwizMi2uiOe"
   
   production:
     stripe_publishable_key: "pk_live_uoExPgxfIG7bBXMAMyqHfB9b"
     stripe_secret_key: "sk_live_KbhHZzgpzWIEsOoBOnatXUjo"

   As for the defaults method naming, I hear you. I'm not sold on it either. I'm not sold on the alternatives set forth yet either. I'll keep rolling that one around.

   When it comes to committing multiple default values for a given key, let's say for the development and test environments while keeping the production value out of source control, there are a couple of options:

   1. Load multiple YAML configuration files, some committed and some not.
   2. Allow environment-dependent default values in the envfile.

   I'm not sure what to do about this one just yet either. I don't like the idea of multiple YAML configuration files because it's harder to track down what values are where. Plus it's more likely that something that's not supposed to get committed does get committed. Here's what option 2 might look like in practice:

   # env.rb
   environment key: "APP_ENV", default: "development"
   
   defaults "env.yml"
   
   string :hello, default: { development: "developer", test: "computer" }

   Anyway, just dumping some thoughts here. Feel free to chime in!
3. laserlemon

   added

   triaged

   v2

   on Jun 25, 2025
4. laserlemon commented on Jul 17, 2025

   

   laserlemon

   on Jul 17, 2025

   OwnerAuthor

   More actions

   👋 Hello, @laserlemon from 5 years ago! You've finally had some time to think about this some more. 😂 Here's where we're at…

   @shekibobo's suggestion of source is so good that I wonder how I never realized it earlier. I also like the environment DSL idea. But I'm definitely second-guessing the hard requirement for a single configuration file.

   I'm also not loving the default: { development: "developer", test: "computer" } syntax because it's conceivable that the default value for a variable could be a Hash! So then we'd have to make guesses at the writer's intent. I'd rather build a DSL where there's no guesswork.

   So for the purposes of finishing this comment so I can get start my work work day… what about something like this:

   # This must be a string, must be sourced from ENV, and must have a default.
   environment key: "APP_ENV", default: "development"
   
   # Maybe this file is committed and contains only safe values. It's loaded only
   # in development and test environments. This file has the lowest precedence
   # but still beats the per-variable defaults defined in this file.
   source "env.dev.yml", environments: ["development", "test"]
   
   # Similar to above. In the test environment, values in this file take precedence
   # over those in env.dev.yml, because the source is specified later in this file.
   source "env.test.yml", environment: "test"
   
   # This file is not committed and contains the real secrets.
   source "env.yml"
   
   # I can imagine a scenario where folks don't even want to use ENV and would
   # rather source all of their configuration from files. So maybe it's helpful to
   # make the ENV source explicit. It would also allow writers to add a file source
   # with even higher precedence than ENV if they so choose. That might be a
   # little unconventional, but I don't see a reason to forbid it.
   source :env
   
   string :hello, default: "world"