• The Elixir build system is called mix.
• mix is an executable installed along with an Elixir installation.
• One of the functions of mix is to build an object code executable by the EVM from Elixir projects.
• This function is implemented by the mix compile command.
• Another function is to test an Elixir project.
• This function is implemented by the mix test command.

• Hex is the package manager for the Erlang ecosystem.
• A package is an Elixir project published on hex.pm.

phoenix 1.7 depends on telemetry 1.2.1.

telemetry is an Erlang package:

Since Elixir packages may depend on Erlang packages, an Erlang build system is necessary to implement the Elixir build system.

See: Guix and Erlang Build System

A test Elixir project that depends on the Erlang telemetry package has been built: test_project.tar.gz.

• We built this project using:
  1. mix new test_project
  2. {:telemetry, "~> 1.2"} is added to mix.exs
  3. Add enough code to show that Elixir uses the Telemetry package.

A Guix package definition has been built for the test project. If this builds, then at least one Elixir package may depend on an Erlang package.

As expected, the build fails:

• The build directory has been kept.
  • /tmp/guix-build-elixir-test-project-0.drv-3
• The telemetry package exists in the environment.
  • Looking at $BUILD_DIR/environment-variables, we find:
    • /gnu/store/…-erlang-telemetry-1.2.1/*

The telemetry app exists:

So, mix should be told to look at:

/gnu/store/…-erlang-telemetry-1.2.1/lib/erlang/lib/

The EVM searches for library directories provided by the OS using ERL_LIBS variable. For instance:

would make the telemetry application available to Elixir. This means that the build systems would have gathered all Erlang dependencies specified in the package inputs to add them to ERL_LIBS.

It builds successfully:

It is the result of this modification of test-package.scm thanks to Hartmut:

This piece of code searches for Erlang dependencies in the inputs field of the package and adds the relevant directories to ERL_LIBS so that necessary applications are found at runtime by the EVM.

Moving forward, at least two plans may be followed: using ERL_LIBS or patching the Application Resource File. We choose to follow the ERL_LIBS plan in this article and the Application Resource File plan in an other article.

See: Application resource file plan.

Since:

• We know that using ERL_LIBS may work.
• We know that Python uses a similar mechanism with PYTHONPATH.

Then:

• We study how Python manages its dependencies.
• We try to apply this knowledge to Elixir.

Counting on the analogy GUIX_ERL_LIBS ~ GUIX_PYTHONPATH, let's find how the value of GUIX_PYTHONPATH is used ; hoping to use GUIX_ERL_LIBS similarly. We have:

In gnu/packages/python.scm, we find:

In gnu/packages/aux-files/python/sitecustomize.py, we find:

# Site-specific customization for Guix.
#
# The program below honors the GUIX_PYTHONPATH environment variable to
# discover Python packages.  File names appearing in this variable that match
# a predefined versioned installation prefix are added to the sys.path.  To be
# considered, a Python package must be installed under the
# 'lib/pythonX.Y/site-packages' directory, where X and Y are the major and
# minor version numbers of the Python interpreter.
          

The code looks for the value of the environment variable GUIX_PYTHONPATH. This variable may be viewed as the set of transitive Python dependencies of the current package. Each dependency then made available to the Python runtime during initialization.

Counting on the analogy GUIX_ERL_LIBS ~ GUIX_PYTHONPATH, let's find how the value of GUIX_PYTHONPATH is computed ; hoping to apply a similar computation to GUIX_ERL_LIBS. In guix/gnu/packages/python.scm, we find:

1. The python-3.10 package defines the GUIX_PYTHONPATH environment variable so that it lists all the Python dependencies in the environment (Guix doc).
2. Python initialization is modified using sitecustomize.py so that all dependencies represented by GUIX_PYTHONPATH are available to the Python runtime.

To make Erlang/Elixir libraries — i.e. applications — available to the EVM, their directories must be added to the code path. To add them to the code path, they may be listed using the ERL_LIBS environment variable.

Any EVM application packaged with Guix — compiled from Elixir or Erlang — can use Elixir or Erlang dependencies, if:

1. The Erlang package defines the GUIX_ERL_LIBS environment variable so that it lists all the Erlang and Elixir dependencies in the environment.
   • Like Python, we use a search-path-specification.
2. erl is wrapped so that ERL_LIBS = GUIX_ERL_LIBS.
   • An Erlang runtime system is started with command erl (doc).
3. The above steps are true for Elixir, except that instead of erl, we have:
   • elixir is wrapped so that ERL_LIBS = GUIX_ERL_LIBS.
   • iex is wrapped so that ERL_LIBS = GUIX_ERL_LIBS.
4. Elixir and Erlang packages dependencies must be declared as propagated inputs.
   1. GUIX_ERL_LIBS is built using the Search Paths capabilities of Guix.
   2. For a dependency to be found by the Search Paths capabilities of Guix, it must exist in the environment.
   3. For a dependency to exist in the environment, it must be a propagated input.

guix install elixir-phoenix works as expected.