Elixir Mix 入门教程

在这份指导手册中,我们将学习创建一个完整的Elixir应用程序,以及监督树、配置、测试等高级概念。

这个程序是一个分布式的键-值存储数据库。我们会把键-值存储在“桶”中,分布存储到多个节点。 我们还会创建一个简单的客户端工具,可以连接任意一个节点,并且能够发送类似以下的命令:

CREATE shopping
OK

PUT shopping milk 1
OK

PUT shopping eggs 3
OK

GET shopping milk
1
OK

DELETE shopping eggs
OK

为了编写这个程序,我们将主要用到以下三个工具:

本章会用Mix来创建我们第一个工程,探索OTP、Mix以及ExUnit的各种特性。

注意: 本手册需要Elixir v0.15.0(1.2.0发布后,这里被改为1.2.0了)或以上。 你可以使用命令elixir -v查看版本。 如果需要,可以参考《Elixir入门手册》第一章节内容安装最新的版本。

如果发现任何错误,请开issue或者发pull request。

当你安装Elixir时,你不仅得到了elixir,elixirc和iex命令, 还得到一个可执行的Elixir脚本叫做mix。

从命令行输入mix new命令来创建我们的第一个工程。 我们需要传递工程名称作为参数(在这里,比如叫做 kv), 然后告诉mix我们的主模块的名字是全大写的KV。 否则按照默认,mix会创建一个主模块,名字是第一个字母大写的工程名称(Kv)。 因为K和V的含义在我们的程序中上是平等关系,所以最好是都用大写:


$ mix new kv --module KV

Mix将创建一个文件夹名叫kv,里面有一些文件:


* creating README.md
* creating .gitignore
* creating mix.exs
* creating config
* creating config/config.exs
* creating lib
* creating lib/kv.ex
* creating test
* creating test/test_helper.exs
* creating test/kv_test.exs

现在简单看看这些创建的文件。

注意: Mix是一个Elixir可执行脚本。这意味着,你要想用mix为名直接调用它, 需要提前将Elixir目录放进系统的环境变量中。否则,你需要使用elixir来执行mix:


$ bin/elixir bin/mix new kv --module KV

你也可以用-S选项来执行elixir,它不管你有没有把mix的目录加入环境变量:


$ bin/elixir -S mix new kv --module KV

一个名叫mix.exs的文件会被自动创建在工程目录中。 它的主要作用是配置你的工程。它的内容如下(略去代码中的注释):


defmodule KV.Mixfile do
  use Mix.Project

  def project do
    [app: :kv,
     version: "0.0.1",
     elixir: "~> 1.2",
     build_embedded: Mix.env == :prod,
     start_permanent: Mix.env == :prod,
     deps: deps]
  end

  def application do
    [applications: [:logger]]
  end

  defp deps do
    []
  end
end

我们的mix.exs定义了两个公共函数: 一个是project,它返回工程的配置信息,如工程名称和版本; 另一个是application,它用来生成应用程序文件。

还有一个私有函数叫做deps,它被project函数调用,里面定义了工程的依赖。 不一定非要把deps定义为一个独立的函数,但是这样做可以使工程的配置文件看起来整洁美观。

Mix还生成了文件lib/kv.ex,其内容是个简单的模块定义:


defmodule KV do
end

以上这个结构就足以编译我们的工程了:


$ cd kv
$ mix compile

将生成:


Compiled lib/kv.ex
Generated kv app
Consolidated List.Chars
Consolidated Collectable
Consolidated String.Chars
Consolidated Enumerable
Consolidated IEx.Info
Consolidated Inspect

注意文件lib/kv.ex被编译,生成了程序manifest文件:kv.app 及一些 协议(参考入门手册)。根据mix.exs的配置,所有编译产出被放在_build目录中。

一旦工程被编译成功,便可以从工程目录启动一个iex会话:


$ iex -S mix

Mix还生成了合适的文件结构,来测试我们的工程。Mix工程一般沿用一些命名规则: 在test目录中,测试文件一般以_test.exs模式命名。 每一个对应一个lib目录中的文件名。 根据这个命名规则,我们已经有了测试lib/kv.ex所需的test/kv_test.exs文件。 只是目前它几乎什么也没做:


defmodule KVTest do
  use ExUnit.Case
  doctest KV

  test "the truth" do
    assert 1 + 1 == 2
  end
end

需要注意几点:

  1. 测试文件使用的扩展名(.exs)即Elixir脚本文件。这很方便,我们不用在跑测试前还编译一次。
  2. 我们定义了一个测试模块名为KVTest,用ExUnit.Case来注入测试API, 并使用宏test/2定义了一个简单的测试;

Mix还生成了一个文件名叫test/test_helper.exs,它负责设置测试框架:


ExUnit.start()

每次Mix执行测试时,这个文件将自动被导入(required)。执行测试,使用命令mix test:


Compiled lib/kv.ex
Generated kv app
[...]
.

Finished in 0.04 seconds (0.04s on load, 0.00s on tests)
1 tests, 0 failures

Randomized with seed 540224

注意,每次运行mix test时,Mix会重新编译源文件,生成新的应用程序。 这是因为Mix支持多套执行环境,我们稍后章节会详细介绍。

另外,ExUnit为每一个成功的测试结果打印一个点,它还会自动随机安排测试顺序。 让我们把测试改成失败看看会发生啥。修改test/kv_test.exs里面的断言,改成:


assert 1 + 1 == 3

现在再次运行mix test(注意这次没有编译行为发生):


1) test the truth (KVTest)
   test/kv_test.exs:5
   Assertion with == failed
   code: 1 + 1 == 3
   lhs:  2
   rhs:  3
   stacktrace:
     test/kv_test.exs:6

Finished in 0.05 seconds (0.05s on load, 0.00s on tests)
1 tests, 1 failures

ExUnit会为每个失败的测试结果打印一个详细的报告。其内容包含了测试名称,失败的代码, 失败断言中==号的左值(lhs)和右值(rhs)。

在错误提示的第二行(测试名称下面那行),是该测试的代码位置。 将这个位置作为参数给mix test命令,则将仅执行该条测试:


$ mix test test/kv_test.exs:5

这个十分有用是吧。 最后是关于错误的追踪栈信息,给出关于测试的额外信息。 包括测试失败的地方,还有原文件中产生失败的具体位置等。

Mix支持“环境”的概念。它允许开发者为某些场景定义不同的编译等动作。 默认地,Mix理解三种环境:

  • :dev - Mix任务的默认执行环境(如编译等操作)
  • :test - mix test使用的环境
  • :prod - 用来将应用程序发布到产品环境

环境配置只对当前工程有效。我们之后会看到,向工程中添加的依赖默认在:prod环境下工作。

可以通过访问mix.exs工程配置文件中的Mix.env函数定义不同的环境配置, 它会以原子形式返回当前的环境。 比如我们用之于:build_embedded和:start_permanent:这两个选项:


def project do
  [...,
   build_embedded: Mix.env == :prod,
   start_permanent: Mix.env == :prod,
   ...]
end

上面代码的含义就是程序在:prod环境中运行的话,则使用那两个选项。

当你编译代码的时候,Elixir把编译产出都置于_build目录。 但是,有些时候Elixir为了避免一些不必要的复制操作, 会在_build目录中创建一些链接指向特定文件而不是copy。 当:build_embedded选项被设置为true时可以制止这种行为, 从而在_build目录中提供执行程序所需的所有文件。

类似地,当:start_permanent选项设置为true的时候,程序会以“Permanent模式”执行。 意思是如果你的程序的监督树挂掉,Erlang虚拟机也会挂掉。 注意在:dev和:test环境中,我们可能不需要这样的行为。 因为在这些环境中,为了troubleshooting等目的,需要保持虚拟机持续运行。

Mix默认使用:dev环境,除非在执行测试时需要用到:test环境。 环境可以随时更改:


$ MIX_ENV=prod mix compile

或在Windows上:


> set /a "MIX_ENV=prod" && mix compile

关于Mix,内容还有很多,我们在编写这个工程的过程中还会陆续接触到一些。 详细信息可以参考Mix的文档。

记住,你可以使用mix的帮助信息来帮助理解一些任务的操作方法,如:


$ mix help TASK

教程来源于Github,感谢Jancd大佬的无私奉献,致敬!

技术教程推荐

机器学习40讲 -〔王天一〕

10x程序员工作法 -〔郑晔〕

面试现场 -〔白海飞〕

Swift核心技术与实战 -〔张杰〕

DDD实战课 -〔欧创新〕

超级访谈:对话张雪峰 -〔张雪峰〕

现代React Web开发实战 -〔宋一玮〕

结构执行力 -〔李忠秋〕

结构沟通力 -〔李忠秋〕