DidactMacros
I'm looking for a thorough delineation regarding the use of the Config module and related directories
I’ve looked in Programming Elixir, and Elixir in Action as well as on this forum (even looking at proposals), in manuals and via search engines; I’ve not really found a sizable body of writing that is dedicated to “config”.
Is there any source that covers how to best format config files, what not to put in them, how to know what mix environments’ responsibilities are (regarding config), how and when to override default environment paths, where to place configuration files (apart from /config) as part of convention, and how import_config works with various args?
Apologies if I missed this material somewhere, but I have search up and down for a couple of days. What I have found is that understanding this aspect of app development in elixir can be critical later on with more advanced collaborative projects.
Marked As Solved
Eiji
Not sure about this, but maybe it’s just me. I’m really quickly learning new things. Simply when I saw in example some_function_call() then I look for it in documentation when needed. Personally I never had a problem understanding the config.
So you were looking at wrong documentation. Your mistake is that you were looking at details (here config) without thinking about general things (here application). Look at the top of mix.exs and it suddenly becomes clear (i.e. use Mix.Project). 
The config.exs is compile-time and code compilation is part of building your application. The building tool is mix and that’s why there’s more documentation. For example you can see environments section of Mix documentation.
Link to all Elixir’s core applications are here:
Could you please give some link? You may saw some old code for other version of Elixir core. Unfortunately macros are more rarely documented. Because of the quoted expressions there are less pattern-matching simply because for example list literals and the ones created using sigil_w have a different AST (Abstract Syntax Tree) representation and simply is_list/1 check may fail for them and also for example variables.
The current documentation uses Path.expand/1 which only accepts Path.t which points to IO.chardata(), so currently atoms does not work.
iex> Path.expand(:example)
** (FunctionClauseError) no function clause matching in IO.chardata_to_string/1
The following arguments were given to IO.chardata_to_string/1:
# 1
:example
Attempted function clauses (showing 2 out of 2):
def chardata_to_string(string) when is_binary(string)
def chardata_to_string(list) when is_list(list)
(elixir 1.16.0) lib/io.ex:687: IO.chardata_to_string/1
(elixir 1.16.0) lib/path.ex:818: Path.expand_home/1
(elixir 1.16.0) lib/path.ex:180: Path.expand/1
iex:1: (file)
Also Liked
tfwright
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”…
ityonemo
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.
danj
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.2
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.
Last Post!
danj
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.2
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"