swendel/nixpkgs
1
0
Fork 0
mirror of https://github.com/SebastianWendel/nixpkgs.git synced 2024-09-20 12:29:02 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #26668 from gleber/fixpoint-erlang-packages

Browse source 
erlang: refactor: build packages per Erlang/OTP version.
This commit is contained in:
Daiderd Jordan 2017-06-22 21:49:30 +02:00 committed by GitHub
parent 86dc6469ba 505508a813
commit aba574c4fa
9 changed files with 338 additions and 182 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/default.nix
View file

@ -26,7 +26,7 @@ pkgs.stdenv.mkDerivation {
extraHeader = ''xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" '';
in ''
{
pandoc '${inputFile}' -w docbook ${lib.optionalString useChapters "--chapters"} \
pandoc '${inputFile}' -w docbook ${lib.optionalString useChapters "--top-level-division=chapter"} \
--smart \
| sed -e 's|<ulink url=|<link xlink:href=|' \
-e 's|</ulink>|</link>|' \

364
doc/languages-frameworks/beam.xml
View file

@ -2,60 +2,120 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="sec-beam">
<title>Beam Languages (Erlang &amp; Elixir)</title>
<title>BEAM Languages (Erlang, Elixir &amp; LFE)</title>
<section xml:id="beam-introduction">
<title>Introduction</title>
<para>
In this document and related Nix expressions we use the term
<emphasis>Beam</emphasis> to describe the environment. Beam is
the name of the Erlang Virtial Machine and, as far as we know,
from a packaging perspective all languages that run on Beam are
interchangable. The things that do change, like the build
system, are transperant to the users of the package. So we make
no distinction.
In this document and related Nix expressions, we use the term,
<emphasis>BEAM</emphasis>, to describe the environment. BEAM is the name
of the Erlang Virtual Machine and, as far as we're concerned, from a
packaging perspective, all languages that run on the BEAM are
interchangeable. That which varies, like the build system, is transparent
to users of any given BEAM package, so we make no distinction.
</para>
</section>
<section xml:id="build-tools">
<section xml:id="beam-structure">
<title>Structure</title>
<para>
All BEAM-related expressions are available via the top-level
<literal>beam</literal> attribute, which includes:
</para>
<itemizedlist>
<listitem>
<para>
<literal>interpreters</literal>: a set of compilers running on the
BEAM, including multiple Erlang/OTP versions
(<literal>beam.interpreters.erlangR19</literal>, etc), Elixir
(<literal>beam.interpreters.elixir</literal>) and LFE
(<literal>beam.interpreters.lfe</literal>).
</para>
</listitem>
<listitem>
<para>
<literal>packages</literal>: a set of package sets, each compiled with
a specific Erlang/OTP version, e.g.
<literal>beam.packages.erlangR19</literal>.
</para>
</listitem>
</itemizedlist>
<para>
The default Erlang compiler, defined by
<literal>beam.interpreters.erlang</literal>, is aliased as
<literal>erlang</literal>. The default BEAM package set is defined by
<literal>beam.packages.erlang</literal> and aliased at the top level as
<literal>beamPackages</literal>.
</para>
<para>
To create a package set built with a custom Erlang version, use the
lambda, <literal>beam.packagesWith</literal>, which accepts an Erlang/OTP
derivation and produces a package set similar to
<literal>beam.packages.erlang</literal>.
</para>
<para>
Many Erlang/OTP distributions available in
<literal>beam.interpreters</literal> have versions with ODBC and/or Java
enabled. For example, there's
<literal>beam.interpreters.erlangR19_odbc_javac</literal>, which
corresponds to <literal>beam.interpreters.erlangR19</literal>.
</para>
<para xml:id="erlang-call-package">
We also provide the lambda,
<literal>beam.packages.erlang.callPackage</literal>, which simplifies
writing BEAM package definitions by injecting all packages from
<literal>beam.packages.erlang</literal> into the top-level context.
</para>
</section>
<section xml:id="build-tools">
<title>Build Tools</title>
<section xml:id="build-tools-rebar3">
<title>Rebar3</title>
<para>
By default Rebar3 wants to manage it's own dependencies. In the
normal non-Nix, this is perfectly acceptable. In the Nix world it
is not. To support this we have created two versions of rebar3,
<literal>rebar3</literal> and <literal>rebar3-open</literal>. The
<literal>rebar3</literal> version has been patched to remove the
ability to download anything from it. If you are not running it a
nix-shell or a nix-build then its probably not going to work for
you. <literal>rebar3-open</literal> is the normal, un-modified
rebar3. It should work exactly as would any other version of
rebar3. Any Erlang package should rely on
<literal>rebar3</literal> and thats really what you should be
using too.
By default, Rebar3 wants to manage its own dependencies. This is perfectly
acceptable in the normal, non-Nix setup, but in the Nix world, it is not.
To rectify this, we provide two versions of Rebar3:
<itemizedlist>
<listitem>
<para>
<literal>rebar3</literal>: patched to remove the ability to download
anything. When not running it via <literal>nix-shell</literal> or
<literal>nix-build</literal>, it's probably not going to work as
desired.
</para>
</listitem>
<listitem>
<para>
<literal>rebar3-open</literal>: the normal, unmodified Rebar3. It
should work exactly as would any other version of Rebar3. Any Erlang
package should rely on <literal>rebar3</literal> instead. See <xref
linkend="rebar3-packages"/>.
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section xml:id="build-tools-other">
<title>Mix &amp; Erlang.mk</title>
<para>
Both Mix and Erlang.mk work exactly as you would expect. There
is a bootstrap process that needs to be run for both of
them. However, that is supported by the
<literal>buildMix</literal> and <literal>buildErlangMk</literal> derivations.
Both Mix and Erlang.mk work exactly as expected. There is a bootstrap
process that needs to be run for both, however, which is supported by the
<literal>buildMix</literal> and <literal>buildErlangMk</literal>
derivations, respectively.
</para>
</section>
</section>
<section xml:id="how-to-install-beam-packages">
<title>How to install Beam packages</title>
<title>How to Install BEAM Packages</title>
<para>
Beam packages are not registered in the top level simply because
they are not relevant to the vast majority of Nix users. They are
installable using the <literal>beamPackages</literal> attribute
set.
BEAM packages are not registered at the top level, simply because they are
not relevant to the vast majority of Nix users. They are installable using
the <literal>beam.packages.erlang</literal> attribute set (aliased as
<literal>beamPackages</literal>), which points to packages built by the
default Erlang/OTP version in Nixpkgs, as defined by
<literal>beam.interpreters.erlang</literal>.
You can list the avialable packages in the
<literal>beamPackages</literal> with the following command:
To list the available packages in
<literal>beamPackages</literal>, use the following command:
</para>
<programlisting>
@ -69,115 +129,152 @@ beamPackages.meck meck-0.8.3
beamPackages.rebar3-pc pc-1.1.0
</programlisting>
<para>
To install any of those packages into your profile, refer to them by
their attribute path (first column):
To install any of those packages into your profile, refer to them by their
attribute path (first column):
</para>
<programlisting>
$ nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.ibrowse
</programlisting>
<para>
The attribute path of any Beam packages corresponds to the name
of that particular package in Hex or its OTP Application/Release name.
The attribute path of any BEAM package corresponds to the name of that
particular package in <link xlink:href="https://hex.pm">Hex</link> or its
OTP Application/Release name.
</para>
</section>
<section xml:id="packaging-beam-applications">
<title>Packaging Beam Applications</title>
<title>Packaging BEAM Applications</title>
<section xml:id="packaging-erlang-applications">
<title>Erlang Applications</title>
<section xml:id="rebar3-packages">
<title>Rebar3 Packages</title>
<para>
There is a Nix functional called
<literal>buildRebar3</literal>. We use this function to make a
derivation that understands how to build the rebar3 project. For
example, the epression we use to build the <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>
project follows.
The Nix function, <literal>buildRebar3</literal>, defined in
<literal>beam.packages.erlang.buildRebar3</literal> and aliased at the
top level, can be used to build a derivation that understands how to
build a Rebar3 project. For example, we can build <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> as
follows:
</para>
<programlisting>
{stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
{ stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
buildRebar3 rec {
name = "hex2nix";
version = "0.0.1";
buildRebar3 rec {
name = "hex2nix";
version = "0.0.1";
src = fetchFromGitHub {
owner = "ericbmerritt";
repo = "hex2nix";
rev = "${version}";
sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
};
src = fetchFromGitHub {
owner = "ericbmerritt";
repo = "hex2nix";
rev = "${version}";
sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
};
beamDeps = [ ibrowse jsx erlware_commons ];
}
</programlisting>
<para>
The only visible difference between this derivation and
something like <literal>stdenv.mkDerivation</literal> is that we
have added <literal>erlangDeps</literal> to the derivation. If
you add your Beam dependencies here they will be correctly
handled by the system.
Such derivations are callable with
<literal>beam.packages.erlang.callPackage</literal> (see <xref
linkend="erlang-call-package"/>). To call this package using the normal
<literal>callPackage</literal>, refer to dependency packages via
<literal>beamPackages</literal>, e.g.
<literal>beamPackages.ibrowse</literal>.
</para>
<para>
If your package needs to compile native code via Rebar's port
compilation mechenism. You should add <literal>compilePort =
true;</literal> to the derivation.
Notably, <literal>buildRebar3</literal> includes
<literal>beamDeps</literal>, while
<literal>stdenv.mkDerivation</literal> does not. BEAM dependencies added
there will be correctly handled by the system.
</para>
<para>
If a package needs to compile native code via Rebar3's port compilation
mechanism, add <literal>compilePort = true;</literal> to the derivation.
</para>
</section>
<section xml:id="erlang-mk-packages">
<title>Erlang.mk Packages</title>
<para>
Erlang.mk functions almost identically to Rebar. The only real
difference is that <literal>buildErlangMk</literal> is called
instead of <literal>buildRebar3</literal>
Erlang.mk functions similarly to Rebar3, except we use
<literal>buildErlangMk</literal> instead of
<literal>buildRebar3</literal>.
</para>
<programlisting>
{ buildErlangMk, fetchHex, cowlib, ranch }:
buildErlangMk {
name = "cowboy";
version = "1.0.4";
src = fetchHex {
pkg = "cowboy";
version = "1.0.4";
sha256 =
"6a0edee96885fae3a8dd0ac1f333538a42e807db638a9453064ccfdaa6b9fdac";
};
beamDeps = [ cowlib ranch ];
{ buildErlangMk, fetchHex, cowlib, ranch }:
meta = {
description = ''Small, fast, modular HTTP server written in
Erlang.'';
license = stdenv.lib.licenses.isc;
homepage = "https://github.com/ninenines/cowboy";
};
buildErlangMk {
name = "cowboy";
version = "1.0.4";
src = fetchHex {
pkg = "cowboy";
version = "1.0.4";
sha256 = "6a0edee96885fae3a8dd0ac1f333538a42e807db638a9453064ccfdaa6b9fdac";
};
beamDeps = [ cowlib ranch ];
meta = {
description = ''
Small, fast, modular HTTP server written in Erlang
'';
license = stdenv.lib.licenses.isc;
homepage = https://github.com/ninenines/cowboy;
};
}
</programlisting>
</section>
<section xml:id="mix-packages">
<title>Mix Packages</title>
<para>
Mix functions almost identically to Rebar. The only real
difference is that <literal>buildMix</literal> is called
instead of <literal>buildRebar3</literal>
Mix functions similarly to Rebar3, except we use
<literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
</para>
<programlisting>
{ buildMix, fetchHex, plug, absinthe }:
buildMix {
name = "absinthe_plug";
version = "1.0.0";
src = fetchHex {
pkg = "absinthe_plug";
version = "1.0.0";
sha256 =
"08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
};
beamDeps = [ plug absinthe];
beamDeps = [ plug absinthe ];
meta = {
description = ''A plug for Absinthe, an experimental GraphQL
toolkit'';
description = ''
A plug for Absinthe, an experimental GraphQL toolkit
'';
license = stdenv.lib.licenses.bsd3;
homepage = "https://github.com/CargoSense/absinthe_plug";
homepage = https://github.com/CargoSense/absinthe_plug;
};
}
</programlisting>
<para>
Alternatively, we can use <literal>buildHex</literal> as a shortcut:
</para>
<programlisting>
{ buildHex, buildMix, plug, absinthe }:
buildHex {
name = "absinthe_plug";
version = "1.0.0";
sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
builder = buildMix;
beamDeps = [ plug absinthe ];
meta = {
description = ''
A plug for Absinthe, an experimental GraphQL toolkit
'';
license = stdenv.lib.licenses.bsd3;
homepage = https://github.com/CargoSense/absinthe_plug;
};
}
</programlisting>
@ -185,18 +282,18 @@ $ nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.ibrowse
</section>
</section>
<section xml:id="how-to-develop">
<title>How to develop</title>
<title>How to Develop</title>
<section xml:id="accessing-an-environment">
<title>Accessing an Environment</title>
<para>
Often, all you want to do is be able to access a valid
environment that contains a specific package and its
dependencies. we can do that with the <literal>env</literal>
part of a derivation. For example, lets say we want to access an
erlang repl with ibrowse loaded up. We could do the following.
Often, we simply want to access a valid environment that contains a
specific package and its dependencies. We can accomplish that with the
<literal>env</literal> attribute of a derivation. For example, let's say
we want to access an Erlang REPL with <literal>ibrowse</literal> loaded
up. We could do the following:
</para>
<programlisting>
~/w/nixpkgs ❯❯❯ nix-shell -A beamPackages.ibrowse.env --run "erl"
$ nix-shell -A beamPackages.ibrowse.env --run "erl"
Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V7.0 (abort with ^G)
@ -237,20 +334,19 @@ $ nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.ibrowse
2>
</programlisting>
<para>
Notice the <literal>-A beamPackages.ibrowse.env</literal>.That
is the key to this functionality.
Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key
to this functionality.
</para>
</section>
<section xml:id="creating-a-shell">
<title>Creating a Shell</title>
<para>
Getting access to an environment often isn't enough to do real
development. Many times we need to create a
<literal>shell.nix</literal> file and do our development inside
of the environment specified by that file. This file looks a lot
like the packaging described above. The main difference is that
<literal>src</literal> points to project root and we call the
package directly.
development. Usually, we need to create a <literal>shell.nix</literal>
file and do our development inside of the environment specified therein.
This file looks a lot like the packaging described above, except that
<literal>src</literal> points to the project root and we call the package
directly.
</para>
<programlisting>
{ pkgs ? import &quot;&lt;nixpkgs&quot;&gt; {} }:
@ -264,18 +360,19 @@ let
name = "hex2nix";
version = "0.1.0";
src = ./.;
erlangDeps = [ ibrowse jsx erlware_commons ];
beamDeps = [ ibrowse jsx erlware_commons ];
};
drv = beamPackages.callPackage f {};
in
drv
drv
</programlisting>
<section xml:id="building-in-a-shell">
<title>Building in a shell</title>
<title>Building in a Shell (for Mix Projects)</title>
<para>
We can leveral the support of the Derivation, regardless of
which build Derivation is called by calling the commands themselv.s
We can leverage the support of the derivation, irrespective of the build
derivation, by calling the commands themselves.
</para>
<programlisting>
# =============================================================================
@ -335,42 +432,43 @@ analyze: build plt
</programlisting>
<para>
If you add the <literal>shell.nix</literal> as described and
user rebar as follows things should simply work. Aside from the
Using a <literal>shell.nix</literal> as described (see <xref
linkend="creating-a-shell"/>) should just work. Aside from
<literal>test</literal>, <literal>plt</literal>, and
<literal>analyze</literal> the talks work just fine for all of
the build Derivations.
<literal>analyze</literal>, the Make targets work just fine for all of the
build derivations.
</para>
</section>
</section>
</section>
<section xml:id="generating-packages-from-hex-with-hex2nix">
<title>Generating Packages from Hex with Hex2Nix</title>
<title>Generating Packages from Hex with <literal>hex2nix</literal></title>
<para>
Updating the Hex packages requires the use of the
<literal>hex2nix</literal> tool. Given the path to the Erlang
modules (usually
<literal>pkgs/development/erlang-modules</literal>). It will
happily dump a file called
<literal>hex-packages.nix</literal>. That file will contain all
the packages that use a recognized build system in Hex. However,
it can't know whether or not all those packages are buildable.
Updating the <link xlink:href="https://hex.pm">Hex</link> package set
requires <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>. Given the
path to the Erlang modules (usually
<literal>pkgs/development/erlang-modules</literal>), it will dump a file
called <literal>hex-packages.nix</literal>, containing all the packages that
use a recognized build system in <link
xlink:href="https://hex.pm">Hex</link>. It can't be determined, however,
whether every package is buildable.
</para>
<para>
To make life easier for our users, it makes good sense to go
ahead and attempt to build all those packages and remove the
ones that don't build. To do that, simply run the command (in
the root of your <literal>nixpkgs</literal> repository). that follows.
To make life easier for our users, try to build every <link
xlink:href="https://hex.pm">Hex</link> package and remove those that fail.
To do that, simply run the following command in the root of your
<literal>nixpkgs</literal> repository:
</para>
<programlisting>
$ nix-build -A beamPackages
</programlisting>
<para>
That will build every package in
<literal>beamPackages</literal>. Then you can go through and
manually remove the ones that fail. Hopefully, someone will
improve <literal>hex2nix</literal> in the future to automate
that.
That will attempt to build every package in
<literal>beamPackages</literal>. Then manually remove those that fail.
Hopefully, someone will improve <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> in the
future to automate the process.
</para>
</section>
</section>

3
pkgs/development/beam-modules/build-hex.nix
View file

@ -1,13 +1,14 @@
{ stdenv, buildRebar3, fetchHex }:
{ name, version, sha256
, builder ? buildRebar3
, hexPkg ? name
, ... }@attrs:
with stdenv.lib;
let
pkg = self: buildRebar3 (attrs // {
pkg = self: builder (attrs // {
src = fetchHex {
pkg = hexPkg;

63
pkgs/development/beam-modules/default.nix
View file

@ -1,16 +1,53 @@
{ stdenv, pkgs }:
{ stdenv, pkgs, erlang, overrides ? (self: super: {}) }:
let
self = rec {
hexPackages = import ./hex-packages.nix { stdenv = stdenv; callPackage = self.callPackage; pkgs = pkgs; };
callPackage = pkgs.lib.callPackageWith (pkgs // self // hexPackages);
buildRebar3 = callPackage ./build-rebar3.nix {};
buildHex = callPackage ./build-hex.nix {};
buildErlangMk = callPackage ./build-erlang-mk.nix {};
buildMix = callPackage ./build-mix.nix {};
inherit (stdenv.lib) fix' extends getVersion versionAtLeast;
## Non hex packages
hex = callPackage ./hex {};
webdriver = callPackage ./webdriver {};
};
in self // self.hexPackages
lib = pkgs.callPackage ./lib.nix {};
# FIXME: add support for overrideScope
callPackageWithScope = scope: drv: args: stdenv.lib.callPackageWith scope drv args;
mkScope = scope: pkgs // scope;
packages = self:
let
defaultScope = mkScope self;
callPackage = drv: args: callPackageWithScope defaultScope drv args;
in
import ./hex-packages.nix {
inherit pkgs stdenv callPackage;
} // {
inherit callPackage erlang;
beamPackages = self;
rebar = callPackage ../tools/build-managers/rebar { };
rebar3-open = callPackage ../tools/build-managers/rebar3 {
hermeticRebar3 = false;
};
rebar3 = callPackage ../tools/build-managers/rebar3 {
hermeticRebar3 = true;
};
hexRegistrySnapshot = callPackage ./hex-registry-snapshot.nix { };
fetchHex = callPackage ./fetch-hex.nix { };
buildRebar3 = callPackage ./build-rebar3.nix {};
buildHex = callPackage ./build-hex.nix {};
buildErlangMk = callPackage ./build-erlang-mk.nix {};
buildMix = callPackage ./build-mix.nix {};
# BEAM-based languages.
elixir = if versionAtLeast (lib.getVersion erlang) "18"
then callPackage ../interpreters/elixir { debugInfo = true; }
else throw "Elixir requires at least Erlang/OTP R18.";
lfe = callPackage ../interpreters/lfe { };
# Non hex packages
hex = callPackage ./hex {};
webdriver = callPackage ./webdriver {};
hex2nix = callPackage ../tools/erlang/hex2nix {};
cuter = callPackage ../tools/erlang/cuter {};
relxExe = callPackage ../tools/erlang/relx-exe {};
};
in fix' (extends overrides packages)

11
pkgs/development/beam-modules/lib.nix
View file

@ -1,4 +1,4 @@
{ pkgs }:
{ pkgs, stdenv }:
rec {
@ -12,6 +12,15 @@ rec {
callPackage = callPackageWith pkgs;
/* Erlang/OTP-specific version retrieval, returns 19 for OTP R19 */
getVersion = x:
let
parse = drv: (builtins.parseDrvName drv).version;
in builtins.replaceStrings ["B" "-"] ["." "."] (
if builtins.isString x
then parse x
else x.version or (parse x.name));
/* Uses generic-builder to evaluate provided drv containing OTP-version
specific data.

20
pkgs/development/beam-modules/mix-bootstrap
View file

@ -3,18 +3,16 @@
%%! -smp enable
%%% ---------------------------------------------------------------------------
%%% @doc
%%% The purpose of this command is to prepare a rebar3 project so that
%%% rebar3 understands that the dependencies are all already
%%% installed. If you want a hygienic build on nix then you must run
%%% this command before running rebar3. I suggest that you add a
%%% `Makefile` to your project and have the bootstrap command be a
%%% dependency of the build commands. See the nix documentation for
%%% The purpose of this command is to prepare a mix project so that mix
%%% understands that the dependencies are all already installed. If you want a
%%% hygienic build on nix then you must run this command before running mix. I
%%% suggest that you add a `Makefile` to your project and have the bootstrap
%%% command be a dependency of the build commands. See the nix documentation for
%%% more information.
%%%
%%% This command designed to have as few dependencies as possible so
%%% that it can be a dependency of root level packages like rebar3. To
%%% that end it does many things in a fairly simplistic way. That is
%%% by design.
%%% This command designed to have as few dependencies as possible so that it can
%%% be a dependency of root level packages like mix. To that end it does many
%%% things in a fairly simplistic way. That is by design.
%%%
%%% ### Assumptions
%%%
@ -37,7 +35,7 @@ main(Args) ->
%% @doc
%% This takes an app name in the standard OTP <name>-<version> format
%% and returns just the app name. Why? because rebar is doesn't
%% and returns just the app name. Why? Because rebar doesn't
%% respect OTP conventions in some cases.
-spec fixup_app_name(file:name()) -> string().
fixup_app_name(Path) ->

20
pkgs/development/tools/build-managers/rebar3/rebar3-nix-bootstrap
View file

@ -146,7 +146,7 @@ make_symlink(Path, TargetFile) ->
%% @doc
%% This takes an app name in the standard OTP <name>-<version> format
%% and returns just the app name. Why? because rebar doesn't
%% and returns just the app name. Why? Because rebar doesn't
%% respect OTP conventions in some cases.
-spec fixup_app_name(string()) -> string().
fixup_app_name(FileName) ->
@ -180,14 +180,14 @@ make_sure_registry_snapshot_exists(RegistrySnapshot) ->
erlang:halt(1)
end.
-spec gather_required_data_from_the_environment(#data{}) -> {ok, map()}.
-spec gather_required_data_from_the_environment(#data{}) -> {ok, #data{}}.
gather_required_data_from_the_environment(ArgData) ->
{ok, ArgData#data{ version = guard_env("version")
, erl_libs = os:getenv("ERL_LIBS", [])
, plugins = os:getenv("buildPlugins", [])
, erl_libs = get_env("ERL_LIBS", [])
, plugins = get_env("buildPlugins", [])
, root = code:root_dir()
, name = guard_env("name")
, compile_ports = nix2bool(os:getenv("compilePorts", ""))
, compile_ports = nix2bool(get_env("compilePorts", ""))
, registry_snapshot = guard_env("HEX_REGISTRY_SNAPSHOT")}}.
-spec nix2bool(any()) -> boolean().
@ -196,9 +196,17 @@ nix2bool("1") ->
nix2bool("") ->
false.
get_env(Name) ->
os:getenv(Name).
get_env(Name, Def) ->
case get_env(Name) of
false -> Def;
Val -> Val
end.
-spec guard_env(string()) -> string().
guard_env(Name) ->
case os:getenv(Name) of
case get_env(Name) of
false ->
stderr("Expected Environment variable ~s! Are you sure you are "
"running in a Nix environment? Either a nix-build, "

2
pkgs/top-level/all-packages.nix
View file

@ -5986,7 +5986,7 @@ with pkgs;
erlangR18 erlangR18_odbc erlangR18_javac erlangR18_odbc_javac
erlangR19 erlangR19_odbc erlangR19_javac erlangR19_odbc_javac;
inherit (beam.packages)
inherit (beam.packages.erlang)
rebar rebar3-open rebar3
hexRegistrySnapshot fetchHex beamPackages
hex2nix cuter relxExe;

35
pkgs/top-level/beam-packages.nix
View file

@ -1,12 +1,13 @@
{ pkgs, stdenv, callPackage, wxGTK30, darwin }:
rec {
lib = import ../development/beam-modules/lib.nix { inherit pkgs; };
lib = callPackage ../development/beam-modules/lib.nix {};
# Each
interpreters = rec {
# R18 is the Default version.
erlang = erlangR18;
# R18 is the default version.
erlang = erlangR18; # The main switch to change default Erlang version.
erlang_odbc = erlangR18_odbc;
erlang_javac = erlangR18_javac;
erlang_odbc_javac = erlangR18_odbc_javac;
@ -44,22 +45,26 @@ rec {
odbcSupport = true;
};
# Other Beam languages.
elixir = callPackage ../development/interpreters/elixir { debugInfo = true; };
lfe = callPackage ../development/interpreters/lfe { };
# Other Beam languages. These are built with `beam.interpreters.erlang`. To
# access for example elixir built with different version of Erlang, use
# `beam.packages.erlangR19.elixir`.
elixir = packages.erlang.elixir;
lfe = packages.erlang.lfe;
};
# Helper function to generate package set with a specific Erlang version.
packagesWith = erlang: callPackage ../development/beam-modules { inherit erlang; };
# Each field in this tuple represents all Beam packages in nixpkgs built with
# appropriate Erlang/OTP version.
packages = rec {
rebar = callPackage ../development/tools/build-managers/rebar { };
rebar3-open = callPackage ../development/tools/build-managers/rebar3 { hermeticRebar3 = false; };
rebar3 = callPackage ../development/tools/build-managers/rebar3 { hermeticRebar3 = true; };
hexRegistrySnapshot = callPackage ../development/beam-modules/hex-registry-snapshot.nix { };
fetchHex = callPackage ../development/beam-modules/fetch-hex.nix { };
beamPackages = callPackage ../development/beam-modules { };
hex2nix = beamPackages.callPackage ../development/tools/erlang/hex2nix { };
cuter = callPackage ../development/tools/erlang/cuter { };
# Packages built with default Erlang version.
erlang = packagesWith interpreters.erlang;
erlangR16 = packagesWith interpreters.erlangR16;
erlangR17 = packagesWith interpreters.erlangR17;
erlangR18 = packagesWith interpreters.erlangR18;
erlangR19 = packagesWith interpreters.erlangR19;
relxExe = callPackage ../development/tools/erlang/relx-exe {};
};
}