View Source Config (Elixir v1.14.0-rc.0)
A simple keyword-based configuration API.
Example
This module is most commonly used to define application configuration,
typically in config/config.exs
:
import Config
config :some_app,
key1: "value1",
key2: "value2"
import_config "#{config_env()}.exs"
import Config
will import the functions config/2
, config/3
config_env/0
, config_target/0
, and import_config/1
to help you manage your configuration.
config/2
and config/3
are used to define key-value configuration
for a given application. Once Mix starts, it will automatically
evaluate the configuration file and persist the configuration above
into :some_app
's application environment, which can be accessed in
as follows:
"value1" = Application.fetch_env!(:some_app, :key1)
Finally, the line import_config "#{config_env()}.exs"
will import
other config files based on the current configuration environment,
such as config/dev.exs
and config/test.exs
.
Config
also provides a low-level API for evaluating and reading
configuration, under the Config.Reader
module.
Important: if you are writing a library to be used by other developers, it is generally recommended to avoid the application environment, as the application environment is effectively a global storage. Also note that the
config/config.exs
of a library is not evaluated when the library is used as a dependency, as configuration is always meant to configure the current project. For more information, read our library guidelines.
Migrating from use Mix.Config
The Config
module in Elixir was introduced in v1.9 as a replacement to
Mix.Config
, which was specific to Mix and has been deprecated.
You can leverage Config
instead of Mix.Config
in three steps. The first
step is to replace use Mix.Config
at the top of your config files by
import Config
.
The second is to make sure your import_config/1
calls do not have a
wildcard character. If so, you need to perform the wildcard lookup
manually. For example, if you did:
import_config "../apps/*/config/config.exs"
It has to be replaced by:
for config <- "../apps/*/config/config.exs" |> Path.expand(__DIR__) |> Path.wildcard() do
import_config config
end
The last step is to replace all Mix.env()
calls in the config files with config_env()
.
Keep in mind you must also avoid using Mix.env()
inside your project files.
To check the environment at runtime, you may add a configuration key:
# config.exs
...
config :my_app, env: config_env()
Then, in other scripts and modules, you may get the environment with
Application.fetch_env!/2
:
# router.exs
...
if Application.fetch_env!(:my_app, :env) == :prod do
...
end
The only files where you may access functions from the Mix
module are
the mix.exs
file and inside custom Mix tasks, which always within the
Mix.Tasks
namespace.
config/runtime.exs
For runtime configuration, you can use the config/runtime.exs
file.
It is executed right before applications start in both Mix and releases
(assembled with mix release
).
Link to this section Summary
Functions
Configures the given root_key
.
Configures the given key
for the given root_key
.
Returns the environment this configuration file is executed on.
Returns the target this configuration file is executed on.
Imports configuration from the given file.
Link to this section Functions
Configures the given root_key
.
Keyword lists are always deep-merged.
Examples
The given opts
are merged into the existing configuration
for the given root_key
. Conflicting keys are overridden by the
ones specified in opts
, unless they are keywords, which are
deep merged recursively. For example, the application configuration
below
config :logger,
level: :warn,
backends: [:console]
config :logger,
level: :info,
truncate: 1024
will have a final configuration for :logger
of:
[level: :info, backends: [:console], truncate: 1024]
Configures the given key
for the given root_key
.
Keyword lists are always deep merged.
Examples
The given opts
are merged into the existing values for key
in the given root_key
. Conflicting keys are overridden by the
ones specified in opts
, unless they are keywords, which are
deep merged recursively. For example, the application configuration
below
config :ecto, Repo,
log_level: :warn,
adapter: Ecto.Adapters.Postgres,
metadata: [read_only: true]
config :ecto, Repo,
log_level: :info,
pool_size: 10,
metadata: [replica: true]
will have a final value of the configuration for the Repo
key in the :ecto
application of:
Application.get_env(:ecto, Repo)
#=> [
#=> log_level: :info,
#=> pool_size: 10,
#=> adapter: Ecto.Adapters.Postgres,
#=> metadata: [read_only: true, replica: true]
#=> ]
Returns the environment this configuration file is executed on.
In Mix projects this function returns the environment this configuration
file is executed on. In releases, the environment when mix release
ran.
This is most often used to execute conditional code:
if config_env() == :prod do
config :my_app, :debug, false
end
Returns the target this configuration file is executed on.
This is most often used to execute conditional code:
if config_target() == :host do
config :my_app, :debug, false
end
Imports configuration from the given file.
In case the file doesn't exist, an error is raised.
If file is a relative, it will be expanded relatively to the directory the current configuration file is in.
Examples
This is often used to emulate configuration across environments:
import_config "#{config_env()}.exs"
Note, however, some configuration files, such as config/runtime.exs
does not support imports, as they are meant to be copied across
systems.