fuchsiaaaaaaaaaaaaaaaaa
one thing I really hate about environment variables as config is there's no way the software will tell you you misstyped a variable name...
@f0x I wish this kind of logging behavior would be more commonplace but everyone seems to think is weird or there's something wrong with it 🙁
@forestjohnson it's iffy for authentication in env variables (which are always iffy imo), but all software should print the rest of their config on startup tbh
@f0x Yeah for mine I did a [stupid hack](https://git.sequentialread.com/forest/threshold/src/branch/multi-tenant/main_client.go#L242-L258)
JSON, YAML, TOML, all can have the same problem but its a lot more normative to warn or even error on unknown properties for those because they have a well defined namespace -- just 1 file.
@f0x all of this could have been avoided if docker / docker-compose had supported a standard, API-driven way to add a file into a container before running it
@f0x thats the really messed up thing about it 💀
@forestjohnson yeah it's such a docker thing really...
NixOS solves this super easily, you can just use builtins.toFile <filename> <contents> which makes sure that string is available as a (config) file to the program you're running
@f0x https://nixos.wiki/wiki/NixOS_on_ARM
There are already quite some community supported SBCs 👀
@forestjohnson yeah, nixos is the best! https://git.pixie.town/f0x/nixos great system orchestration
@f0x In theory it could, but most software doesn't.
If we can coax the software to print its configuration file to the log on startup, at least it will indirectly let you know, because the configuration value in question will be missing. If it always prints the config on startup by default, this can even happen before we considered that the configuration part wasn't working.
In theory if the environment variable is prefixed, it might be possible to directly warn about unknown environment variables and/or low
levenshtein distance between the env var's name and a known configuration variable name.
I bet folks have been scared to implement this kind of logic for env-var-based config because of how the environment variables are often all thrown into the same global namespace, so there's a possibility of collisions with other programs running on the same machine.
The warning message for the unknown env var(s) would have to warn you that "this warning itself might be spurious" 🙃 that classic aged 30-40 years old technology flavor