-
Notifications
You must be signed in to change notification settings - Fork 21.9k
Add Rails::Application#config_for #16129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Might use a better example, like: # config/production.rb
BCX::Application.configure do
config.middleware.use ExceptionNotifier, config_for(:exception_notification)
end Otherwise looks good! |
test "config_for loads custom configuration from yaml files" do | ||
app_file 'config/custom.yml', <<-RUBY | ||
development: | ||
custom: 'custom value' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be clearer to read if this was called something else? As it is, the test later uses 'custom' in two places to refer to different things...
If Rails will provide canonical way to manage env-specific configuration from yaml, should it be in scope to have inheritable application yaml configuration, overridable per environment, similar to how the ruby config in environment.rb/application.rb is inherited and overridable by environments/foo.rb? |
@egilburg not sure if I follow. Is not YAML inheritance sufficient? development: &default
foo:
bar:
production:
<<*default
bar: |
I haven’t found that helpful or useful for my usage of this feature. These config files are usually pretty small, and it gives more clarity to have the env declarations together. On Jul 10, 2014, at 3:59 PM, Eugene Gilburg notifications@github.com wrote:
|
@rafaelfranca, sure, but this is a bit of sugar to match the sugar we get from the Ruby config. So instead of: default: &default
foo: 'bar'
production:
<< &default
baz: 'production_baz' We'd have: application:
foo: 'bar'
production:
baz: 'production_baz' It only saves a few lines, but the idea that it follows the pattern Rails uses where environment/production.rb inherits everything in application.rb, helping to group concerns together. |
I really believe we should not try to include new features on yaml parsing 😄 |
Ah, Eugene, I see what you mean. I thought you wanted separate files per env. I’m with Rafael, though. YAML is hairy enough as it is. I don’t think we want to add to that. On Jul 10, 2014, at 4:04 PM, Eugene Gilburg notifications@github.com wrote:
|
+1 to @dhh @rafaelfranca please keep yaml parsing as is 😅 |
This wouldn't be so much parsing as merging the already parsed values: data = YAML.load(ERB.new(yaml.read).result) || {}
data['application'] || {}).merge(data[Rails.env] || {}).presence If it's not considered useful from behavior perspective, sure. Just pointing out we don't need to change any of the actual Yaml parsing itself. |
Also, if yaml has no env key defined, it seems current implementation returns |
This would lead some questions like: Why database.yml doesn't work this way? Why it doesn't work when I don't use I think we should stick with what yaml give to us. About the |
require "#{app_path}/config/environment" | ||
end | ||
|
||
assert_equal "Could not load configuration. No such file - #{app_path}/config/custom.yml" ,exception.message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpicking but the comma's place is wrong.
Nice patch! 👍 Maybe we can also simplify |
I can't simplify |
This is a convenience for loading configuration for the current Rails environment.
Add Rails::Application#config_for
require "erb" | ||
(YAML.load(ERB.new(yaml.read).result) || {})[Rails.env] || {} | ||
else | ||
raise "Could not load configuration. No such file - #{yaml}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason behind raising the default RuntimeError VS something more specific such as IOError or reraising the Errno::ENOENT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, fine to raise re-raise, as long as we use that new message.
On Feb 16, 2015, at 10:35, Michael Deering notifications@github.com wrote:
In railties/lib/rails/application.rb:
url: http://localhost:3001
namespace: my_app_development
# config/production.rb
MyApp::Application.configure do
config.middleware.use ExceptionNotifier, config_for(:exception_notification)
end
- def config_for(name)
yaml = Pathname.new("#{paths["config"].existent.first}/#{name}.yml")
if yaml.exist?
require "yaml"
require "erb"
(YAML.load(ERB.new(yaml.read).result) || {})[Rails.env] || {}
else
raise "Could not load configuration. No such file - #{yaml}"
Any reason behind raising the default RuntimeError VS something more specific such as IOError or reraising the Errno::ENOENT?
—
Reply to this email directly or view it on GitHub.
This is a convenience for loading configuration for the current Rails
environment.
cc @dhh