Commits on Oct 18, 2024

1. Treat deserialization errors from empty env vars as unset env var …

   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?

   

   LukasKalbertodt committed Oct 18, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 035fd45
   • Browse repository at this point

   Copy the full SHA

   035fd45 View commit details

   Browse the repository at this point in the history

2. Add docs and tests about "empty var" behavior

   

   LukasKalbertodt committed Oct 18, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 06db476
   • Browse repository at this point

   Copy the full SHA

   06db476 View commit details

   Browse the repository at this point in the history