MIX(1)

πŸ“¦
version 1.20.4 Β· 4 versions
, in alpine 3.24, arch rolling, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu stonking

πŸ’– MIX(1) β€” the software project management tool πŸ’–

ok so bestie. this is the manual page for mix, from the General Commands Manual, and honestly? she's iconic. let's get into it 🫢


✨ NAME ✨

mix β€” The software project management tool


🌸 SYNOPSIS 🌸

mix [TASK] [project_name]
elixir [OPTIONS] -S mix [TASK] [project_name]

πŸ¦‹ DESCRIPTION πŸ¦‹

so mix is out here doing two jobs at once and slaying both: it organizes your code into projects, and then it maintains them. for the maintenance part it's got some genuinely advanced features β€” dependency management, packaging, preparing documentation, testing, the whole little buffet πŸ’…

look at the SYNOPSIS again, specifically the second way of running it. the tea is that mix is literally just an Elixir script. that's it. so you can invoke it through elixir(1) exactly like any other script, and that's lowkey useful when you wanna run mix with particular options. periodt.


πŸ‘‘ DEFINITIONS πŸ‘‘

all of the mix functionality lives inside a set of tasks. a task is a piece of code written in Elixir that's meant to solve one particular problem. like programs, a lot of tasks take input parameters and/or support options that slightly modify their behavior β€” but some of them just don't, and that's fine too, we don't judge πŸ’œ

there are two types of tasks:

  • local tasks β€” the ones that become available after you install this or that archive
  • built-in tasks β€” the ones offered by mix itself

and the run task gets executed by default if you haven't specified any other one. no cap.

even though the greater part of mix is tasks, this man page does not contain the help info for each individual one, because mix is self-descriptive like that ✨. so just use the help task and you can pull up both the full list of local/built-in tasks and the info for a particular task. iykyk.

two more definitions, quick fire:

  • An archive, in terms of Erlang/OTP, is the ZIP file with the .ez extension which contains a precompiled OTP application with all its dependencies [1].
  • An application is an entity that helps to combine sets of components into a single unit to simplify their reusing in other systems [2].

🌈 ENVIRONMENT 🌈

  • MIX_ARCHIVES β€” lets you specify the directory into which the archives should be installed (see mix help archive.install). by default the ~/.mix/archives directory is used for this purpose.
  • MIX_DEBUG β€” when it's set, it outputs debug information about each task before running it.
  • MIX_ENV β€” lets you specify which environment should be used. the dev environment is used by default if you haven't specified another one.

sometimes you genuinely have to use a particular set of configuration parameter values, or perform particular steps when you compile or run a project (or in some other cases, bestie, life is chaos). the mix environments let you group values of configuration parameters and steps together so you can switch between them by specifying the necessary environment via MIX_ENV. chef's kiss πŸ‘©β€πŸ³πŸ’‹

  • MIX_TARGET β€” lets you specify which target should be used. the host target is used by default if you haven't specified another one.
  • MIX_EXS β€” lets you change the full path to the mix.exs file (see the FILES section). the most obvious use case is having more than one copy of mix.exs in a project, but it's worth noting that MIX_EXS should be used only if the mix environments (see above) are not enough to solve the problem. like, don't reach for it first, okay? πŸ™ˆ
  • MIX_HOME β€” path to Mix's home directory, stores configuration files and scripts used by Mix
  • MIX_INSTALL_DIR β€” Specifies directory where Mix.install/2 keeps installs cache
  • MIX_INSTALL_FORCE β€” Runs Mix.install/2 with empty install cache
  • MIX_PATH β€” lets you expand the code path. if the MIX_PATH environment variable has a value which consists of multiple paths, they must be colon-separated (for Unix-like operating systems) or semicolon-separated (for Windows).

as mentioned above, there are two types of tasks: local and built-in. these tasks are always visible to mix because the directories they live in are part of the code path. so if a task belongs to neither one type nor the other, MIX_PATH is how you tell mix where it should search for that task. communication, queen πŸ’…

  • MIX_QUIET β€” when it's set, it does not print information messages to the terminal. silence. blessed silence. 🀫

πŸŽ€ FILES πŸŽ€

  • mix.exs β€” Contains the most significant information related to the project, such as its name, version, list of dependencies and so on. as a rule, the file is named mix.exs and located at the top of the project's source tree, but you can change the full path to it using the MIX_EXS environment variable (see the ENVIRONMENT section). she's flexible πŸ’–
  • mix.lock β€” Allows locking down the project dependencies with a proper version range before performing any updates. it's useful when you know that your project is incompatible with newer versions of certain dependencies. the file is located at the top of the project's source tree as well as mix.exs (see above).

⭐ REFERENCES ⭐

[1] https://www.erlang.org/doc/man/code.html#id103620

[2] https://www.erlang.org/doc/design_principles/applications.html


πŸ”₯ SEE ALSO πŸ”₯

elixir(1), elixirc(1), iex(1)


πŸ’œ AUTHOR πŸ’œ

Elixir is maintained by The Elixir Team.

This manual page was contributed by Evgeny Golyshev.

Copyright (c) 2012 Plataformatec.

Copyright (c) 2021 The Elixir Team.


🧚 INTERNET RESOURCES 🧚


ok that's the whole page, you're fully caught up bestie ✨ one last thing before you go: this beauty ships from Debian and she's dated May 27, 2015 β€” a vintage icon, honestly, still serving πŸ“πŸ’… go write something amazing, mwah 🫢