Quoted numeric values should be returned as strings, not parsed into numbers
reger opened this issue · 6 comments
If you have something like my_setting: "2.1"
in your file, it gets returned as a Float
, the same as my_setting: 2.1
does. I would expect an explicitly quoted value to be returned as a string. I know I can set config.env_parse_values = false
, but I don't want all numerics returned as strings.
Yes, you are right. They should not be parsed if explicitly quited. I would welcome a PR if you have some time to look into this?
@pkuczynski I'll try to find some time. If I do, I'll submit a PR.
Cool! Thanks in advance :)
FWIW config.env_parse_values
only affects values set with using environment variables to override your settings. It should have no effect when parsing settings from YAML files.
I'd be interested in knowing more about how you're using the gem, though, because I'm surprised that you're seeing quoted values being returned as Float
s. I'm not able to reproduce this behavior in a test case.
git apply <<'PATCH'
diff --git a/spec/fixtures/settings.yml b/spec/fixtures/settings.yml
index 2d04b72..2e9a1a7 100644
--- a/spec/fixtures/settings.yml
+++ b/spec/fixtures/settings.yml
@@ -12,6 +12,7 @@ databases:
# ...
#
size: 1
+my_setting: "2.1"
server: google.com
1: "one"
photo_sizes:
diff --git a/spec/options_spec.rb b/spec/options_spec.rb
index 5b0bb91..76c9eac 100644
--- a/spec/options_spec.rb
+++ b/spec/options_spec.rb
@@ -50,6 +50,10 @@ describe Config::Options do
expect(config['size']).to eq(1)
end
+ it 'should return strings when a floating-point number in quotes is stored as the value' do
+ expect(config['my_setting']).to eq("2.1")
+ end
+
it 'should add keys from the added file' do
expect(config['tvrage']['service_url']).to eq('http://services.tvrage.com')
end
PATCH
The test passes, indicating that it got a String back.
@cjlarose and now I'm seeing the same behavior you are. I tried it a few different ways today and was seeing it come back as a float. Not sure what was going on or what might have caused what I was seeing, but it all seems fine now. Apologies for the wild goose chase @pkuczynski. I'll go ahead and close this since it seems to be working as expected now. (and it's going to drive me bonkers as to why I was seeing that behavior...)
I added a few more tests in #296 to ensure it works as designed