3 ms·

Thanks! I had thought of about 3 of those, but they aren't really wins for most of my deployment environments (and some of the downsides still are major downsid

Thanks! I had thought of about 3 of those, but they aren't really wins for most of my deployment environments (and some of the downsides still are major downsides for me; one thing I love about config files is I can provide a readme or schema in the same place to define what all the config params are and what they do). For #4, what do you mean? If running in a container it's not really an issue, but if I'm loading a couple of different dependencies/apps in the same container, or running without containers, name collisions have always been a concern. Set up a chroot, or start renaming things (i.e., "PORT" conflicts really quickly). Or are you saying supply them in the shell, or...?

paulddraper 7y ago
> For #4, what do you mean? I mean that one process can have COLOR=blue and another can have COLOR=red with no conflict. PORT=123 COLOR=blue ./myapp PORT=456 COLOR=red ./myapp Yes you can chroot, run in containers, use only relative file paths, etc. There aren't any irremovable differences between env vars and files; env vars are basically /proc/ files with widespread runtime support.