LukasKalbertodt
Treat deserialization errors from empty env vars as unset env var
@jdx what do you think about this potential solution to your issue?
Fixes #35
I'm a bit worried that this might seem too much like magic, but I think this is just the most useful behavior in all situations I can think of. This covers not only Booleans, but also numbers and anything else for which an empty string is not a valid value. It also leaves types with empty strings as valid values untouched.
I've been thinking about how this behavior could confuse users. And I could only think of two cases:
-
A config value has a default value, and the user thinks that empty string is a valid value, when in fact it isn't. Then, setting
FOO=will result in the default value, when the user expected an empty string. Here, a clear error "empty string invalid" would be more helpful. -
A config value with a type that can be deserialized from empty string, but the user thinks it cannot. Maybe the config value is a list of numbers, where "" is just an empty list, but the user thought it was a single number. Then setting
FOO=means setting the value to an empty list.
Not sure if any of these cases will happen often enough or is important enough to not merge this?
