Theoretically Home · Elixir School is where such a resource would be found if it existed. Maybe an effort could be organized to submit something. I certainly agree it is an important piece that deserves a comprehensive overview, especially with confusion around “config” vs “runtime”…

thing to know is that there are two important files:

• config.exs which is compile-time configuration
• runtime.exs which is run-time configuration

Often config.exs will be set up to punt to “.exs” but this must be explicit. Note that configuration is overridden “as written” so if something is set in test.exs it can be overridden by anything after your import_config call.

Also note that if you’re writing a library, all the stuff in your config.exs will NOT be called when your library is being compiled by your library’s user.

There are a bunch of mechanisms but the most core problem is configuration in deployment. However, I have found the best approach is to tackle that problem first then work backwards to development. Of course starting at the end isn’t possible when you’re just starting with all of this.

The most common deployment model is containers, but what I’m going to describe works well with any model of deployment and in development, the benefit there being a single mechanism can be used and tested through the entire life cycle.

There are two ways to inject deployment time data into a container, files and the environment. I’ve tried the first and I don’t recommend it. Getting a file injected in a container is a pain. I’ve been using the environment in combination with some assistance from a package (I wrote) Jetenv — Jetenv v0.1.1
which gives full access to the entire application environment and supports types and complex values.

With this approach you can configure any part of your application with predictable names and have full visibility into what’s being configured. It works well with secret managers since they work best with env vars. You can inject multi-line strings (think certificates) as well. And the same approach, though with different values typically, works in development. Source an env file and you’re ready to go. This is also nice because it provides a template for devops in building the deployment environment.

Are you asking in general or do you have an example of a language/framework that has something along the lines of what you’re looking for?

Hmm … config is just … config, so “not much” happens in them. It’s almost as same as json or yaml configuration files except that you can add some extra Elixir code to them. The biggest thing about config files is how they works across environments and that’s almost all. All the basics are covered in Config documentations.

Do you mean code formatting? It’s as same as in any other source code file, see the documentation for mix format task.

Almost everything - it’s easier to say what to put to them. Basically all you need is fetching the OS environment variables and using config_env() - both are well covered in Config documentation.

What “responsibilities” are you referencing to? Simply read the documentation what you are able to configure and use the ones you need. There are no “business logic” inside config or something like that. Simply configure your app and dependencies as you do in json or yaml files, but with a bit more of flexibility for example to fetch some data (like above in OS environment variables) and use them for configuration.

Best practice is rather to follow community standards as it’s easier for others to read your code. However nobody is limiting you what and how you do in your pet projects. If you want name them as you want. The default ones should be clear enough, so most people simply don’t touch configuration file names i.e. there is no need to do that.

Elixir does not have a framework which forces you to do something in specific direction, but gives you a good defaults. As above usually nobody is changing them. They are in config directory in both pet and huge business projects as keeping them in well known default location makes the most sense.

Simply you are passing a file name of file you want to import. There is no magic here except that you cannot import things in runtime.exs (also explained in Config documentation).

The materials are created when needed. If someone is asked to deploy a phoenix app to AWS then having production knowledge the tutorial is shared. Sometimes people have a problem finding something in documentation, but as above changing config naming is not common. Not much people were ever thinking about that and therefore there are not much resources about it. Same is for a database. By default in most projects PostgreSQL is more than enough. You are free to learn about other databases, but again if you don’t need it then you don’t have to learn about it.

Yes it is, but not so detailed. As long as you follow documentation and forum you should be fine. For most cases there are tools to help you like credo.

Possibly related: