View Source Introduction to Mix
In this guide, we will build a complete Elixir application, with its own supervision tree, configuration, tests, and more.
The requirements for this guide are (see elixir -v
):
- Elixir 1.15.0 onwards
- Erlang/OTP 24 onwards
The application works as a distributed key-value store. We are going to organize key-value pairs into buckets and distribute those buckets across multiple nodes. We will also build a simple client that allows us to connect to any of those nodes and send requests such as:
CREATE shopping
OK
PUT shopping milk 1
OK
PUT shopping eggs 3
OK
GET shopping milk
1
OK
DELETE shopping eggs
OK
In order to build our key-value application, we are going to use three main tools:
OTP (Open Telecom Platform) is a set of libraries that ships with Erlang. Erlang developers use OTP to build robust, fault-tolerant applications. In this chapter we will explore how many aspects from OTP integrate with Elixir, including supervision trees, event managers and more;
Mix is a build tool that ships with Elixir that provides tasks for creating, compiling, testing your application, managing its dependencies and much more;
ExUnit is a test-unit based framework that ships with Elixir.
In this chapter, we will create our first project using Mix and explore different features in OTP, Mix, and ExUnit as we go.
Source code
The final code for the application built in this guide is in this repository and can be used as a reference.
Is this guide required reading?
This guide is not required reading in your Elixir journey. We'll explain.
As an Elixir developer, you will most likely use one of the many existing frameworks when writing your Elixir code. Phoenix covers web applications, Ecto communicates with databases, you can craft embedded software with Nerves, Nx powers machine learning and AI projects, Membrane assembles audio/video processing pipelines, Broadway handles data ingestion and processing, and many more. These frameworks handle the lower level details of concurrency, distribution, and fault-tolerance, so you, as a user, can focus on your own needs and demands.
On the other hand, if you want to learn the foundations these frameworks are built upon, and the abstractions that power the Elixir ecosystem, this guide will give you a tour through several important concepts.
Our first project
When you install Elixir, besides getting the elixir
, elixirc
, and iex
executables, you also get an executable Elixir script named mix
.
Let's create our first project by invoking mix new
from the command line. We'll pass the project path as the argument (kv
, in this case). By default, the application name and module name will be retrieved from the path. So we tell Mix that our main module should be the all-uppercase KV
, instead of the default, which would have been Kv
:
$ mix new kv --module KV
Mix will create a directory named kv
with a few files in it:
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/kv.ex
* creating test
* creating test/test_helper.exs
* creating test/kv_test.exs
Let's take a brief look at those generated files.
Executables in the
PATH
Mix is an Elixir executable. This means that in order to run
mix
, you need to have bothmix
andelixir
executables in your PATH. That's what happens when you install Elixir.
Project compilation
A file named mix.exs
was generated inside our new project folder (kv
) and its main responsibility is to configure our project. Let's take a look at it:
defmodule KV.MixProject do
use Mix.Project
def project do
[
app: :kv,
version: "0.1.0",
elixir: "~> 1.11",
start_permanent: Mix.env() == :prod,
deps: deps()
]
end
# Run "mix help compile.app" to learn about applications
def application do
[
extra_applications: [:logger]
]
end
# Run "mix help deps" to learn about dependencies
defp deps do
[
# {:dep_from_hexpm, "~> 0.3.0"},
# {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"},
]
end
end
Our mix.exs
defines two public functions: project
, which returns project configuration like the project name and version, and application
, which is used to generate an application file.
There is also a private function named deps
, which is invoked from the project
function, that defines our project dependencies. Defining deps
as a separate function is not required, but it helps keep the project configuration tidy.
Mix also generates a file at lib/kv.ex
with a module containing exactly one function, called hello
:
defmodule KV do
@moduledoc """
Documentation for KV.
"""
@doc """
Hello world.
## Examples
iex> KV.hello()
:world
"""
def hello do
:world
end
end
This structure is enough to compile our project:
$ cd kv
$ mix compile
Will output:
Compiling 1 file (.ex)
Generated kv app
The lib/kv.ex
file was compiled and an application manifest named kv.app
was generated. All compilation artifacts are placed inside the _build
directory using the options defined in the mix.exs
file.
Once the project is compiled, you can start a iex
session inside the project by running the command below. The -S mix
is necessary to load the project in the interactive shell:
$ iex -S mix
We are going to work on this kv
project, making modifications and trying out the latest changes from a iex
session. While you may start a new session whenever there are changes to the project source code, you can also recompile the project from within iex
with the recompile
helper, like this:
iex> recompile()
Compiling 1 file (.ex)
:ok
iex> recompile()
:noop
If anything had to be compiled, you see some informative text, and get the :ok
atom back, otherwise the function is silent, and returns :noop
.
Running tests
Mix also generated the appropriate structure for running our project tests. Mix projects usually follow the convention of having a <filename>_test.exs
file in the test
directory for each file in the lib
directory. For this reason, we can already find a test/kv_test.exs
corresponding to our lib/kv.ex
file. It doesn't do much at this point:
defmodule KVTest do
use ExUnit.Case
doctest KV
test "greets the world" do
assert KV.hello() == :world
end
end
It is important to note a couple of things:
the test file is an Elixir script file (
.exs
). This is convenient because we don't need to compile test files before running them;we define a test module named
KVTest
, in which weuse ExUnit.Case
to inject the testing API;we use one of the imported macros,
ExUnit.DocTest.doctest/1
, to indicate that theKV
module contains doctests (we will discuss those in a later chapter);we use the
ExUnit.Case.test/2
macro to define a simple test;
Mix also generated a file named test/test_helper.exs
which is responsible for setting up the test framework:
ExUnit.start()
This file will be required by Mix every time before we run our tests. We can run tests with:
$ mix test
Compiled lib/kv.ex
Generated kv app
..
Finished in 0.04 seconds
1 doctest, 1 test, 0 failures
Randomized with seed 540224
Notice that by running mix test
, Mix has compiled the source files and generated the application manifest once again. This happens because Mix supports multiple environments, which we will discuss later in this chapter.
Furthermore, you can see that ExUnit prints a dot for each successful test and automatically randomizes tests too. Let's make the test fail on purpose and see what happens.
Change the assertion in test/kv_test.exs
to the following:
assert KV.hello() == :oops
Now run mix test
again (notice this time there will be no compilation):
1) test greets the world (KVTest)
test/kv_test.exs:5
Assertion with == failed
code: assert KV.hello() == :oops
left: :world
right: :oops
stacktrace:
test/kv_test.exs:6: (test)
.
Finished in 0.05 seconds
1 doctest, 1 test, 1 failure
For each failure, ExUnit prints a detailed report, containing the test name with the test case, the code that failed and the values for the left side and right side (RHS) of the ==
operator.
In the second line of the failure, right below the test name, there is the location where the test was defined. If you copy the test location in full, including the file and line number, and append it to mix test
, Mix will load and run just that particular test:
$ mix test test/kv_test.exs:5
This shortcut will be extremely useful as we build our project, allowing us to quickly iterate by running a single test.
Finally, the stacktrace relates to the failure itself, giving information about the test and often the place the failure was generated from within the source files.
Automatic code formatting
One of the files generated by mix new
is the .formatter.exs
. Elixir ships with a code formatter that is capable of automatically formatting our codebase according to a consistent style. The formatter is triggered with the mix format
task. The generated .formatter.exs
file configures which files should be formatted when mix format
runs.
To give the formatter a try, change a file in the lib
or test
directories to include extra spaces or extra newlines, such as def hello do
, and then run mix format
.
Most editors provide built-in integration with the formatter, allowing a file to be formatted on save or via a chosen keybinding. If you are learning Elixir, editor integration gives you useful and quick feedback when learning the Elixir syntax.
For companies and teams, we recommend developers to run mix format --check-formatted
on their continuous integration servers, ensuring all current and future code follows the standard.
You can learn more about the code formatter by checking the format task documentation or by reading the release announcement for Elixir v1.6, the first version to include the formatter.
Environments
Mix provides the concept of "environments". They allow a developer to customize compilation and other options for specific scenarios. By default, Mix understands three environments:
:dev
— the one in which Mix tasks (likecompile
) run by default:test
— used bymix test
:prod
— the one you will use to run your project in production
The environment applies only to the current project. As we will see in future chapters, any dependency you add to your project will by default run in the :prod
environment.
Customization per environment can be done by accessing the Mix.env/0
in your mix.exs
file, which returns the current environment as an atom. That's what we have used in the :start_permanent
options:
def project do
[
...,
start_permanent: Mix.env() == :prod,
...
]
end
When true, the :start_permanent
option starts your application in permanent mode, which means the Erlang VM will crash if your application's supervision tree shuts down. Notice we don't want this behaviour in dev and test because it is useful to keep the VM instance running in those environments for troubleshooting purposes.
Mix will default to the :dev
environment, except for the test
task that will default to the :test
environment. The environment can be changed via the MIX_ENV
environment variable:
$ MIX_ENV=prod mix compile
Or on Windows:
> set "MIX_ENV=prod" && mix compile
Mix in production
Mix is a build tool and, as such, it is not expected to be available in production. Therefore, it is recommended to access
Mix.env/0
only in configuration files and insidemix.exs
, never in your application code (lib
).
Exploring
There is much more to Mix, and we will continue to explore it as we build our project. A general overview is available on the Mix documentation and you can always invoke the help task to list all available tasks:
$ mix help
$ mix help compile
Now let's move forward and add the first modules and functions to our application.