Great work Paul! Thank you!
Pinned the thread for a few days to help ensure it’s not missed 
AstonJ
tme_317
Great work @bitwalker!!
Looking at the source and reading the docs it looks like REPLACE_OS_VARS still works if you want to continue doing that from the system environment… but assuming the new Config Provider reading runtime config from .exs, .json, .toml, .yml, :httpc, etc etc is now the recommended way to do it?
Is REPLACE_OS_VARS deprecated or is it staying supported indefinitely for backward compatibility?
0
bitwalker
It’s fine for module docs, and basic markdown, but I found it insufficient for guides with more “complex” content - namely content with asides/notes/warnings/etc. It was hard to draw attention to items of importance in the docs, so things were often missed by people. The new docs are much cleaner formatting in that regard. I actually do still generate the “normal” ExDocs documentation, which you can access from the sidebar via Module Documentation 
Yes, that is my recommendation, and I believe the core team more or less supports that assertion as well, but I don’t want to speak for them. The reason for that is the application environment is effectively global state - using it directly in your code which cares about some piece of configuration means you have tied that code to this global state. This makes testing more difficult, as you can’t test multiple configuration side-by-side, and changing that config in test setup may impact other tests. It also makes code more difficult to reason about, in the sense that something external can change the configuration at any time, so you need to be able to react to those changes correctly, or your code will likely fail.
This is why I recommend fetching all your config in the start/2 function of your application callback module, and then pushing it down your supervisor tree as parameters to the different components in the tree. Supervisors can in turn pass these parameters to workers, and they can store them in their state for use during operation. This is more or less an extension of normal functional programming practices - your processes are just functions acting on the state they are given (this of course ignores the varies ways processes are otherwise stateful, but that state is generally local, and therefore easier to reason about). The less you depend on the app env (or global state in general), the easier it is to predict the behavior of the system based on the initial inputs.
If your app env is entirely static, then it’s less of a concern - but you still have the issue of testing multiple configurations; that global state will make things a lot more painful. If you can just pass in configuration to each component, it is a lot easier to test a bunch of different scenarios in parallel. Passing in configuration applies even to things like registered names - ideally you should be able to start multiple instances of what would normally be a singleton process in your tests, by giving a name where you would normally default to __MODULE__.
It’s early in the morning for me and I’m wandering a bit, but I hope that clarifies the reasoning - hopefully someone will come along and clarify further
It is staying for the time being, since it is still needed for vm.args, and there is the question of backwards compatibility of course. I am pursuing a path which would extend config providers to VM flags as well, in which case we could theoretically deprecate REPLACE_OS_VARS, but we’re not there yet (it is likely going to be quite some time before the pieces are all in place for that).
Config providers are the recommended way to do configuration moving forward, but you can still use REPLACE_OS_VARS as before, for the time being - the simplest migration path is to simply create a config.exs to handle setting the various config settings you need environment values for, and use the Elixir config provider.
6
tcoopman
It’s entirely clear. I agree that it’s a better practice this way. I was just wondering if there was an other reason than that it’s a better programming practice. Maybe I should have clarified my question better.
Thanks!
0
jeremyjh
What if I have modules that need configuration, but do not need to be servers? I wouldn’t want to guide people towards creating GenServer just because they need configuration data at runtime. Your comments about testing are valid; the only way I’ve dealt with this is having setup and teardown code that sets and clears configuration.
1
LostKobrakai
tcoopman
Completely agree, it would be nice if elixir had partial application for things like this though (oh, one can dream )
0
jeremyjh
That is a guide for designing libraries. In an application, the parameters have to come from somewhere.
0
LostKobrakai
You’re right. I didn’t think about that before posting. Using the application env is probably the way to go in that case. But even for your own code I think it’s good to push the need for global state as far out as possible and reasonable. The possibility for sometimes needing to run two different configurations side by side exists for both your own code as well as for libraries.
1
