Comments (2)
Priority of variables loaded, from lowest to highest:
- Defaults declared in the
Envfile
, i.e.string :foo, default: "Foo"
- Values declared in
.env.yml
files. Last declaration wins, overriding previous declarations of the same named variable. 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.
from figaro.
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:
- Load multiple YAML configuration files, some committed and some not.
- 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!
from figaro.
Related Issues (20)
- Can't push application.yml keys to heroku
- figaro heroku:set => “Could not find command heroku:set” HOT 1
- Using with docker and ENV.fetch HOT 1
- ar
- Override contents of generated `application.yml`
- Figaro 2 HOT 3
- Options for Figaro on Elastic BeanStalk HOT 2
- Not working HOT 1
- Environment variables in config/keycloak.yml files, not supported?
- Herarchical structure
- Project status? HOT 15
- Remove escape characters when loading environment values
- Rails and heroku failing tests
- Any npm packages that could use the same secrets? HOT 4
- Starting Rails app through `foreman` doesn't load ENV vars on `config/puma.rb` file
- What do you think about HashiCorp Vault integration?
- `visit_Psych_Nodes_Alias': Unknown alias: shared (Psych::BadAlias) error with ruby 3.1 HOT 3
- Project status (2022) HOT 2
- Undefined method exists? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from figaro.