Comments (9)
I have two suggestions about interface of the feature functionality:
Convention Over Configuration Approach:
Enforce a standardized file organization for configurations. For example, files should be loaded in the following sequence:
- Basic Configuration: Always loaded first (
settings.yml
). - General Configuration Files: Placed in a default directory and applied across all environments (
settings/default/separated_config.yml
,settings/default/subdir/another_separated_config.yml
). - Environment-Specific Configuration: Overrides for specific environments (
settings/production.yml
). - Overloading Configuration Files: Allows further customization within specific environments (
settings/production/separated_config.yml
,settings/production/subdir/another_separated_config.yml
).
Potential Risk: If users already have some files insettings/default
, they might encounter issues after updating the configuration gem. The new version could attempt to process these files, leading to unexpected behavior.
Extending Configuration:
Provide a mechanism to modify the order of configuration files loaded by the Config.process_settings_files
method:
Config.setup do |config|
config.process_settings_files do |settings_files|
# Add files to the beginning of the list
settings_files.unshift('config/settings/default/separated_config.yml')
# Append files to the end of the list
settings_files << 'config/settings/default/another/separated_config.yml'
# Or redefine settings_files
settings_files = ['some_config.yml']
settings_files
end
end
This approach offers flexibility in configuring the loading order, ensuring users can prioritize their configuration files as needed.
I can try to prepare PR
from config.
I think you're hitting on all of things that are important to consider
- Rails users, broadly, are accustomed to convention-over-configuration. The default Railtie already loads
config/development.yml
for example if loading Rails in development mode. Conversely, when loaded outside of Rails, users are expected to be explicit about which files are loaded (they must callConfig.load_and_set_settings
themselves) - Ideally, changes would be made an a backward-compatible way. Loading additional paths by default in a version bump is probably fine, but removing them should be avoided
I think the idea of being able to have control over the order over which files are loaded, and I think the suggested API for config.process_settings_files
would make sense for Rails projects, where there is essentially a "default" set of settings files. For non-Rails use cases, though, it doesn't really make sense to be passed the "default" set of settings files since there really isn't one. I think I'd be more inclined to have something where the user just gives the explicit list of files (either as an Array
or as a block that yields an Array
)
Config.setup do |config|
config.default_settings_sources = [
"config/settings.yaml"
]
end
The default value for the new config.default_settings_sources
setting can just be empty. Or if you're in a Rails project, it should be set to basically Config.setting_files(::Rails.root.join('config'), ::Rails.env)
. If they want to express their list of settings files by manipulating the default list of files programmatically, they can by calling Config.setting_files
explicitly.
Config.setup do |config|
config.default_settings_sources = do
settings_files = Config.setting_files(::Rails.root.join('config'), ::Rails.env)
settings_files.unshift('config/settings/default/separated_config.yml')
settings_files << 'config/settings/default/another/separated_config.yml'
end
end
What do you think?
from config.
Thinking about it a bit more, I guess both approaches depart from what I think is the original design of the gem:
Config.setup
is used configure the behavior of the gem (without actually specifying the literal list of files).Config.load_and_set_settings
actually takes in the list of files. For non-Rails projects, this must be called explicitly. In Rails projects, this is called automatically in the Railtie. In fact, calling it fromconfig/initializers/config.rb
will actually be ignored.
This distinction is interesting to me because Config.setup
is used to specify things that are not related to the list of files to load like how merging settings hashes should behave and which constant to use (by default, Settings
), but also things that are definitely related to where settings should come from (e.g. use_env
and, more recently, file_name
and dir_name
). file_name
and dir_name
, I think exist largely because in a Rails project, the user doesn't have a lot of control over the actual list of settings files. Those two options only really have an effect when calling Config.setting_files
.
I'm not 100% bought-in that this present distinction between config and data (the actual list of files) is the perfect API, but I also want to respect the precedent and I think being able to specify the list of settings files in both Config.setup
and Config.load_and_set_settings
would be confusing.
Therefore, I'm thinking the most straightforward solution to this problem is to just make it so that if a Rails user calls Config.load_and_set_settings
in config/initializers/config.rb
, then the Railtie shouldn't also call the same function (and thereby essentially overwrite the settings loaded in the initializer). The API for Config.load_and_set_settings
already gives users the ultimate flexibility in what files are loaded. The actual problem, I think, is just that the Railtie clobbers any use of that method by doing its own Config.load_and_set_settings
.
So for Rails uses that are completely bought in to the default list of settings files, they don't have to call Config.load_and_set_settings
themselves. But for Rails users that actually do want to customize the list of files, they are welcome to by calling Config.load_and_set_settings
in the initializer with whatever list of files they like.
from config.
I understand your position and agree that there is a reason to stick to the original plan.
I like the idea of having Railtie not call Config.load_and_set_settings
if the user has already called it before.
I tried to think about how this could break backward compatibility, but I couldn't find any issues. reload_from_files
, which is called at runtime but later than the initial initialization, so it seems there shouldn't be any problems with it. If users, for some reason, called Config.load_and_set_settings
earlier, Railtie still did not take this into account.
Then the project's config might look like this:
# app/initializers/config.rb in a Rails project
Config.setup do |config|
Config.load_and_set_settings(file_list)
end
And if the configuration is already defined (load_and_set_settings
has already been loaded), then we do not perform the reloading.
class Railtie < ::Rails::Railtie
def preload
...
return if Object.const_defined?(Config.const_name)
# Parse the settings before any of the initializers
Config.load_and_set_settings(
Config.setting_files(::Rails.root.join('config'), ::Rails.env)
)
...
from config.
Yeah, that's perfect. Would you be interested in opening a PR?
from config.
Yes, I will try
from config.
I'm not found a way to test it yet.
I need to first execute the Config.Setup
code, and after that it should execute Config::Integrations::Rails::Railtie.preload
But all specs runs after Config::Integrations::Rails::Railtie.preload
. So we can not test it with standard bundle exec appraisal rails...
from config.
Yeah, there's not a good existing test pattern to use for this case. There are a few Rails apps in spec/app
, but currently we just run the tests after executing require_relative "app/#{app_name}/config/environment"
. That's useful for running the complete test suite under the environment of a particular Ruby/Rails version combination, but indeed this "pollutes" the test environment if we're trying to test something about the Rails boot sequence itself.
Without completely reorganizing the test suite, the most straightforward approach I see is to test the Railtie behavior is something like
- Write a new file to
Rails.root.join('config', 'initializers', 'config.rb')
- Write any necessary YAML files e.g.
Rails.root.join('config', 'settings.yml')
- Make assertions on
Settings
based by interacting with the current Rails app via the CLI (e.g../bin/rails runner 'puts Settings.expected_key'
). This way, the Rails app will be loaded in a realistic way (the Railtie should run, then the initializers as normal) and it isn't polluted by the fact that the test process itself has already loaded the Rails app. - Delete the temporary files
We can rinse and repeat this pattern for a few tests
- Without any
config.rb
, the default setting files are loaded (anything inconfig/settings.yml
for example) - With a
config.rb
, but without any use ofConfig.load_and_set_settings
, the desired settings apply (for examplefile_name
ordir_name
), and the same default setting files are still loaded (iffile_name
is set toconfig
, thenconfig.yml
is loaded) - With a
config.rb
that callsConfig.load_and_set_settings
, the desired settings apply and only the specified files are loaded (and not any other yml files likeconfig/settings.yml
)
from config.
Thank you for great advice! I added tests
from config.
Related Issues (20)
- Is it possible to reference another configuration in a YAML file? HOT 2
- Unexpected formatting of ENV variable values HOT 6
- Pioneer's question HOT 1
- Preserve newlines while using embedded Ruby HOT 2
- Error using Ruby 3.1.0 : Psych::DisallowedClass: Tried to load unspecified class: Time HOT 2
- avoid Hash monkey patch when loading DeepMerge HOT 2
- Hash sources get clobbered in `Settings.reload!` HOT 1
- ENV variables not loaded with config HOT 12
- Compability with Rails engine HOT 3
- Feature Request: Rake Task to generate env-file HOT 1
- Help with beef please HOT 1
- Released Version 4.1.0 still uses removed method `File.exists?` HOT 7
- minimum, maximum keys are conflicted with active_support methods. HOT 8
- Extend Rails integration to application HOT 3
- Environment variables not loaded anymore after upgrading to Rails 6.1.7.3 HOT 2
- How to use/mock in rspec? HOT 3
- Allow to use custom filename && directory name to store configs HOT 2
- Converting to hash is creating an error (Ruby 3.2.2, config 5.0, Rails 6.1) HOT 1
- Misspelling in tagline: Pandrino HOT 1
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 config.