* There is a reason for autoloading: faster development. Even though you should not usually need to make app-specific configuration changes outside of the main environment.rb and each environment-specific config (development.rb, etc.), if you do, you might consider putting them into a module in an autoload path, and make sure that the fully-qualified path (A::B::C maps to something like app/models/a/b/c.rb) is correct, so that it autoloads without trouble.
* Some suggest putting constants for frequently used values in a file somewhere under config/initializers. That way Rails doesn't complain when reloading them. But, that doesn't autoload if you make changes in development.
* You can extend a Module that is autoloaded with methods that are "marked" with module_function :method_name to become private class methods on the class that extends them. This way you have non-inheriting methods that basically act like config variables.
* You can just use class_attribute in Rails to define inheritable attributes and then use self.the_class_attr_name = something to set them in the body of the class for configuration.
* attr_accessor :some_var_name, @@some_class_var, @some_instance_var, a hash, a Struct, or a OpenStruct are fine ways to hold config values and can be set inline for class vars, in the initialize method for instance vars, or methods called by other hooks, depending on what you need.
* Usually avoid $some_global_var as there is no way to tell whether it has been defined nor whether it has been set explicitly to nil.
author of rails_config here. rails_config is sort of nice because you can use ERB so mix your regular settings along with ENV settings
That said, it's not been a terribly well maintained project. Haven't had time, needs help! I still use 0.2.5 since that's the only one that works for me :)
Additional things to think about:
* https://github.com/railsjedi/rails_config for local developer config
* There is a reason for autoloading: faster development. Even though you should not usually need to make app-specific configuration changes outside of the main environment.rb and each environment-specific config (development.rb, etc.), if you do, you might consider putting them into a module in an autoload path, and make sure that the fully-qualified path (A::B::C maps to something like app/models/a/b/c.rb) is correct, so that it autoloads without trouble.
* Some suggest putting constants for frequently used values in a file somewhere under config/initializers. That way Rails doesn't complain when reloading them. But, that doesn't autoload if you make changes in development.
* You can extend a Module that is autoloaded with methods that are "marked" with module_function :method_name to become private class methods on the class that extends them. This way you have non-inheriting methods that basically act like config variables.
* You can just use class_attribute in Rails to define inheritable attributes and then use self.the_class_attr_name = something to set them in the body of the class for configuration.
* attr_accessor :some_var_name, @@some_class_var, @some_instance_var, a hash, a Struct, or a OpenStruct are fine ways to hold config values and can be set inline for class vars, in the initialize method for instance vars, or methods called by other hooks, depending on what you need.
* Usually avoid $some_global_var as there is no way to tell whether it has been defined nor whether it has been set explicitly to nil.