Mix is a command-line utility that manages Elixir projects. Use it to create new projects, manage a project’s dependencies, run tests, and run your code. If you have Elixir installed, you also have mix. Try running it now:
| | $ mix help |
| | mix # Run the default task (current: mix run) |
| | mix archive # List all archives |
| | mix archive.build # Archive this project into a .ez file |
| | : : : : |
| | mix new # Create a new Elixir project |
| | mix run # Run the given file or expression |
| | mix test # Run a project's tests |
| | iex -S mix # Start IEx and run the default task |
This is a list of the standard tasks that come with mix. (Your list may be a little different, depending on your version of Elixir.) For more information on a particular task, use mix help taskname.
| | $ mix help deps |
| | |
| | List all dependencies and their status. |
| | |
| | Dependencies must be specified in the `mix.exs` file in one of |
| | the following formats: |
| | . . . |
You can write your own mix tasks, for a project and to share between projects.[20]
Each Elixir project lives in its own directory tree. If you use mix to manage this tree, then you’ll follow the mix conventions (which are also the conventions of the Elixir community). We’ll use these conventions in the rest of this chapter.
We’ll call our project issues, so it will go in a directory named issues. We’ll create this directory using mix.
At the command line, navigate to a place where you want this new project to live, and type
| | $ mix new issues |
| | * creating README.md |
| | : : |
| | * creating test |
| | * creating test/test_helper.exs |
| | * creating test/issues_test.exs |
| | |
| | Your mix project was created successfully. |
| | You can use mix to compile it, test it, and more: |
| | |
| | cd issues |
| | mix test |
| | |
| | Run `mix help` for more commands. |
In tree form, the newly created files and directories look like this:
| | issues |
| | ├── .formatter.exs |
| | ├── .gitignore |
| | ├── README.md |
| | ├── config |
| | │ └── config.exs |
| | ├── lib |
| | │ └── issues.ex |
| | ├── mix.exs |
| | └── test |
| | ├── issues_test.exs |
| | └── test_helper.exs |
Change into the issues/ directory. This is a good time to set up version control. I use Git, so I do
| | $ git init |
| | $ git add . |
| | $ git commit -m "Initial commit of new project" |
(I don’t want to clutter the book with version-control stuff, so that’s the last time I’ll mention it. Make sure you follow your own version-control practices as we go along.)
Our new project contains three directories and some files.
Configuration used by the source code formatter
Lists the files and directories generated as by-products of the build and not to be saved in the repository.
A place to put a description of your project (in Markdown format). If you store your project on GitHub, this file’s contents will appear on the project’s home page.
Eventually we’ll put some application-specific configuration here.
This is where our project’s source lives. Mix has already added a top-level module (issues.ex in our case).
This source file contains our project’s configuration options. We will be adding stuff to this as our project progresses.
A place to store our tests. Mix has already created a helper file and a stub for unit tests of the issues module.
Now our job is to add our code. But before we do, let’s think a little about the implementation.