Introduction to Mix — Elixir v1.16.3

Search documentation of Elixir

# 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 both `mix` and `elixir` 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:

1. the test file is an Elixir script file (`.exs`). This is convenient because we don't need to compile test files before running them;

2. we define a test module named `KVTest`, in which we `use ExUnit.Case` to inject the testing API;

3. we use one of the imported macros, `ExUnit.DocTest.doctest/1`, to indicate that the `KV` module contains doctests (we will discuss those in a later chapter);

4. 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 (like `compile`) run by default
- `:test` — used by `mix 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 inside `mix.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.

← Previous Page Domain-Specific Languages (DSLs)
Next Page → Simple state management with agents