diff --git a/doc/beam-users-guide.xml b/doc/beam-users-guide.xml
new file mode 100644
index 00000000000..c1a4c90bc27
--- /dev/null
+++ b/doc/beam-users-guide.xml
@@ -0,0 +1,376 @@
+
+
+ User's Guide to the Beam Infrastructure
+
+ Beam Languages (Erlang & Elixir) on Nix
+
+ In this document and related Nix expressions we use the term
+ Beam 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.
+
+
+
+ Build Tools
+
+ Rebar3
+
+ 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,
+ rebar3 and rebar3-open. The
+ rebar3 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. rebar3-open is the normal, un-modified
+ rebar3. It should work exactly as would any other version of
+ rebar3. Any Erlang package should rely on
+ rebar3 and thats really what you should be
+ using too.
+
+
+
+ Mix & Erlang.mk
+
+ 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
+ buildMix and buildErlangMk derivations.
+
+
+
+
+
+
+ How to install Beam packages
+
+ 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 beamPackages attribute
+ set.
+
+ You can list the avialable packages in the
+ beamPackages with the following command:
+
+
+
+$ nix-env -f "<nixpkgs>" -qaP -A beamPackages
+beamPackages.esqlite esqlite-0.2.1
+beamPackages.goldrush goldrush-0.1.7
+beamPackages.ibrowse ibrowse-4.2.2
+beamPackages.jiffy jiffy-0.14.5
+beamPackages.lager lager-3.0.2
+beamPackages.meck meck-0.8.3
+beamPackages.rebar3-pc pc-1.1.0
+
+
+ To install any of those packages into your profile, refer to them by
+ their attribute path (first column):
+
+
+$ nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
+
+
+ The attribute path of any Beam packages corresponds to the name
+ of that particular package in Hex or its OTP Application/Release name.
+
+
+
+ Packaging Beam Applications
+
+ Erlang Applications
+
+ Rebar3 Packages
+
+ There is a Nix functional called
+ buildRebar3. 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 hex2nix
+ project follows.
+
+
+ {stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
+
+ buildRebar3 rec {
+ name = "hex2nix";
+ version = "0.0.1";
+
+ src = fetchFromGitHub {
+ owner = "ericbmerritt";
+ repo = "hex2nix";
+ rev = "${version}";
+ sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
+ };
+
+ beamDeps = [ ibrowse jsx erlware_commons ];
+ }
+
+
+ The only visible difference between this derivation and
+ something like stdenv.mkDerivation is that we
+ have added erlangDeps to the derivation. If
+ you add your Beam dependencies here they will be correctly
+ handled by the system.
+
+
+ If your package needs to compile native code via Rebar's port
+ compilation mechenism. You should add compilePort =
+ true; to the derivation.
+
+
+
+ Erlang.mk Packages
+
+ Erlang.mk functions almost identically to Rebar. The only real
+ difference is that buildErlangMk is called
+ instead of buildRebar3
+
+
+ { buildErlangMk, fetchHex, cowlib, ranch }:
+ 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";
+ };
+ }
+
+
+
+ Mix Packages
+
+ Mix functions almost identically to Rebar. The only real
+ difference is that buildMix is called
+ instead of buildRebar3
+
+
+ { buildMix, fetchHex, plug, absinthe }:
+ buildMix {
+ name = "absinthe_plug";
+ version = "1.0.0";
+ src = fetchHex {
+ pkg = "absinthe_plug";
+ version = "1.0.0";
+ sha256 =
+ "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
+ };
+ 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";
+ };
+ }
+
+
+
+
+
+ How to develop
+
+ Accessing an Environment
+
+ 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 env
+ part of a derivation. For example, lets say we want to access an
+ erlang repl with ibrowse loaded up. We could do the following.
+
+
+ ~/w/nixpkgs ❯❯❯ 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)
+ 1> m(ibrowse).
+ Module: ibrowse
+ MD5: 3b3e0137d0cbb28070146978a3392945
+ Compiled: January 10 2016, 23:34
+ Object file: /nix/store/g1rlf65rdgjs4abbyj4grp37ry7ywivj-ibrowse-4.2.2/lib/erlang/lib/ibrowse-4.2.2/ebin/ibrowse.beam
+ Compiler options: [{outdir,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/ebin"},
+ debug_info,debug_info,nowarn_shadow_vars,
+ warn_unused_import,warn_unused_vars,warnings_as_errors,
+ {i,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/include"}]
+ Exports:
+ add_config/1 send_req_direct/7
+ all_trace_off/0 set_dest/3
+ code_change/3 set_max_attempts/3
+ get_config_value/1 set_max_pipeline_size/3
+ get_config_value/2 set_max_sessions/3
+ get_metrics/0 show_dest_status/0
+ get_metrics/2 show_dest_status/1
+ handle_call/3 show_dest_status/2
+ handle_cast/2 spawn_link_worker_process/1
+ handle_info/2 spawn_link_worker_process/2
+ init/1 spawn_worker_process/1
+ module_info/0 spawn_worker_process/2
+ module_info/1 start/0
+ rescan_config/0 start_link/0
+ rescan_config/1 stop/0
+ send_req/3 stop_worker_process/1
+ send_req/4 stream_close/1
+ send_req/5 stream_next/1
+ send_req/6 terminate/2
+ send_req_direct/4 trace_off/0
+ send_req_direct/5 trace_off/2
+ send_req_direct/6 trace_on/0
+ trace_on/2
+ ok
+ 2>
+
+
+ Notice the -A beamPackages.ibrowse.env.That
+ is the key to this functionality.
+
+
+
+ Creating a Shell
+
+ Getting access to an environment often isn't enough to do real
+ development. Many times we need to create a
+ shell.nix file and do our development inside
+ of the environment specified by that file. This file looks a lot
+ like the packageing described above. The main difference is that
+ src points to project root and we call the
+ package directly.
+
+
+{ pkgs ? import "<nixpkgs"> {} }:
+
+with pkgs;
+
+let
+
+ f = { buildRebar3, ibrowse, jsx, erlware_commons }:
+ buildRebar3 {
+ name = "hex2nix";
+ version = "0.1.0";
+ src = ./.;
+ erlangDeps = [ ibrowse jsx erlware_commons ];
+ };
+ drv = beamPackages.callPackage f {};
+
+in
+ drv
+
+
+ Building in a shell
+
+ We can leveral the support of the Derivation, regardless of
+ which build Derivation is called by calling the commands themselv.s
+
+
+# =============================================================================
+# Variables
+# =============================================================================
+
+NIX_TEMPLATES := "$(CURDIR)/nix-templates"
+
+TARGET := "$(PREFIX)"
+
+PROJECT_NAME := thorndyke
+
+NIXPKGS=../nixpkgs
+NIX_PATH=nixpkgs=$(NIXPKGS)
+NIX_SHELL=nix-shell -I "$(NIX_PATH)" --pure
+# =============================================================================
+# Rules
+# =============================================================================
+.PHONY= all test clean repl shell build test analyze configure install \
+ test-nix-install publish plt analyze
+
+all: build
+
+guard-%:
+ @ if [ "${${*}}" == "" ]; then \
+ echo "Environment variable $* not set"; \
+ exit 1; \
+ fi
+
+clean:
+ rm -rf _build
+ rm -rf .cache
+
+repl:
+ $(NIX_SHELL) --run "iex -pa './_build/prod/lib/*/ebin'"
+
+shell:
+ $(NIX_SHELL)
+
+configure:
+ $(NIX_SHELL) --command 'eval "$$configurePhase"'
+
+build: configure
+ $(NIX_SHELL) --command 'eval "$$buildPhase"'
+
+install:
+ $(NIX_SHELL) --command 'eval "$$installPhase"'
+
+test:
+ $(NIX_SHELL) --command 'mix test --no-start --no-deps-check'
+
+plt:
+ $(NIX_SHELL) --run "mix dialyzer.plt --no-deps-check"
+
+analyze: build plt
+ $(NIX_SHELL) --run "mix dialyzer --no-compile"
+
+
+
+ If you add the shell.nix as described and
+ user rebar as follows things should simply work. Aside from the
+ test, plt, and
+ analyze the talks work just fine for all of
+ the build Derivations.
+
+
+
+
+
+ Generating Packages from Hex with Hex2Nix
+
+ Updating the Hex packages requires the use of the
+ hex2nix tool. Given the path to the Erlang
+ modules (usually
+ pkgs/development/erlang-modules). It will
+ happily dump a file called
+ hex-packages.nix. 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.
+
+
+ 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 nixpkgs repository). that follows.
+
+
+$ nix-build -A beamPackages
+
+
+ That will build every package in
+ beamPackages. Then you can go through and
+ manually remove the ones that fail. Hopefully, someone will
+ improve hex2nix in the future to automate
+ that.
+
+
+
diff --git a/doc/erlang-users-guide.xml b/doc/erlang-users-guide.xml
deleted file mode 100644
index 074ae50b1c0..00000000000
--- a/doc/erlang-users-guide.xml
+++ /dev/null
@@ -1,305 +0,0 @@
-
-
-User's Guide to the Erlang Infrastructure
-
- Build Tools
-
- 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,
- rebar3 and rebar3-open. The
- rebar3 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. rebar3-open is the normal, un-modified
- rebar3. It should work exactly as would any other version of
- rebar3. Any Erlang package should rely on
- rebar3 and thats really what you should be
- using too.
-
-
-
-
- How to install Erlang packages
-
- Erlang 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 erlangPackages attribute set.
-
- You can list the avialable packages in the
- erlangPackages with the following command:
-
-
-
-$ nix-env -f "<nixpkgs>" -qaP -A erlangPackages
-erlangPackages.esqlite esqlite-0.2.1
-erlangPackages.goldrush goldrush-0.1.7
-erlangPackages.ibrowse ibrowse-4.2.2
-erlangPackages.jiffy jiffy-0.14.5
-erlangPackages.lager lager-3.0.2
-erlangPackages.meck meck-0.8.3
-erlangPackages.rebar3-pc pc-1.1.0
-
-
- To install any of those packages into your profile, refer to them by
- their attribute path (first column):
-
-
-$ nix-env -f "<nixpkgs>" -iA erlangPackages.ibrowse
-
-
- The attribute path of any Erlang packages corresponds to the name
- of that particular package in Hex or its OTP Application/Release name.
-
-
-
- Packaging Erlang Applications
-
- Rebar3 Packages
-
- There is a Nix functional called
- buildRebar3. 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 hex2nix
- project follows.
-
-
-{stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
-
-buildRebar3 rec {
- name = "hex2nix";
- version = "0.0.1";
-
- src = fetchFromGitHub {
- owner = "ericbmerritt";
- repo = "hex2nix";
- rev = "${version}";
- sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
- };
-
- erlangDeps = [ ibrowse jsx erlware_commons ];
-}
-
-
- The only visible difference between this derivation and
- something like stdenv.mkDerivation is that we
- have added erlangDeps to the derivation. If
- you add your Erlang dependencies here they will be correctly
- handled by the system.
-
-
- If your package needs to compile native code via Rebar's port
- compilation mechenism. You should add compilePort =
- true; to the derivation.
-
-
-
-
- Hex Packages
-
- Hex packages are based on Rebar packages. In fact, at the moment
- we can only compile Hex packages that are buildable with
- Rebar3. Packages that use Mix and other build systems are not
- supported. That being said, we know a lot more about Hex and can
- do more for you.
-
-
-{ buildHex }:
- buildHex {
- name = "esqlite";
- version = "0.2.1";
- sha256 = "1296fn1lz4lz4zqzn4dwc3flgkh0i6n4sydg501faabfbv8d3wkr";
- compilePort = true;
-}
-
-
- For Hex packages you need to provide the name, the version, and
- the Sha 256 digest of the package and use
- buildHex to build it. Obviously, the package
- needs to have already been published to Hex.
-
-
-
-
- How to develop
-
- Accessing an Environment
-
- 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 env
- part of a derivation. For example, lets say we want to access an
- erlang repl with ibrowse loaded up. We could do the following.
-
-
- ~/w/nixpkgs ❯❯❯ nix-shell -A erlangPackages.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)
- 1> m(ibrowse).
- Module: ibrowse
- MD5: 3b3e0137d0cbb28070146978a3392945
- Compiled: January 10 2016, 23:34
- Object file: /nix/store/g1rlf65rdgjs4abbyj4grp37ry7ywivj-ibrowse-4.2.2/lib/erlang/lib/ibrowse-4.2.2/ebin/ibrowse.beam
- Compiler options: [{outdir,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/ebin"},
- debug_info,debug_info,nowarn_shadow_vars,
- warn_unused_import,warn_unused_vars,warnings_as_errors,
- {i,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/include"}]
- Exports:
- add_config/1 send_req_direct/7
- all_trace_off/0 set_dest/3
- code_change/3 set_max_attempts/3
- get_config_value/1 set_max_pipeline_size/3
- get_config_value/2 set_max_sessions/3
- get_metrics/0 show_dest_status/0
- get_metrics/2 show_dest_status/1
- handle_call/3 show_dest_status/2
- handle_cast/2 spawn_link_worker_process/1
- handle_info/2 spawn_link_worker_process/2
- init/1 spawn_worker_process/1
- module_info/0 spawn_worker_process/2
- module_info/1 start/0
- rescan_config/0 start_link/0
- rescan_config/1 stop/0
- send_req/3 stop_worker_process/1
- send_req/4 stream_close/1
- send_req/5 stream_next/1
- send_req/6 terminate/2
- send_req_direct/4 trace_off/0
- send_req_direct/5 trace_off/2
- send_req_direct/6 trace_on/0
- trace_on/2
- ok
- 2>
-
-
- Notice the -A erlangPackages.ibrowse.env.That
- is the key to this functionality.
-
-
-
- Creating a Shell
-
- Getting access to an environment often isn't enough to do real
- development. Many times we need to create a
- shell.nix file and do our development inside
- of the environment specified by that file. This file looks a lot
- like the packageing described above. The main difference is that
- src points to project root and we call the
- package directly.
-
-
-{ pkgs ? import "<nixpkgs"> {} }:
-
-with pkgs;
-
-let
-
- f = { buildHex, ibrowse, jsx, erlware_commons }:
- buildHex {
- name = "hex2nix";
- version = "0.1.0";
- src = ./.;
- erlangDeps = [ ibrowse jsx erlware_commons ];
- };
- drv = erlangPackages.callPackage f {};
-
-in
- drv
-
-
- Building in a shell
-
- Unfortunatly for us users of Nix, Rebar isn't very cooperative
- with us from the standpoint of building a hermetic
- environment. When building the rebar3 support we had to do some
- sneaky things to get it not to go out and pull packages on its
- own. Also unfortunately, you have to do some of the same things
- when building a project inside of a Nix shell.
-
-
-
- Run rebar3-nix-bootstrap every time
- dependencies change
-
-
- Set Home to the current directory.
-
-
-
- If you do these two things then Rebar will be happy with you. I
- codify these into a makefile. Forunately, rebar3-nix-bootstrap
- is idempotent and fairly quick. so you can run it as often as
- you like.
-
-
-# =============================================================================
-# Rules
-# =============================================================================
-.PHONY= all test clean repl shell build test analyze bootstrap
-
-all: test
-
-clean:
- rm -rf _build
- rm -rf .cache
-
-repl:
- nix-shell --run "erl"
-
-shell:
- nix-shell --run "bash"
-
-bootstrap:
- nix-shell --pure --run "rebar3-nix-bootstrap"
-
-build: bootstrap
- nix-shell --pure --run "HOME=$(CURDIR) rebar3 compile"
-
-analyze: bootstrap
- nix-shell --pure --run "HOME=$(CURDIR) rebar3 do compile,dialyzer"
-
-test: bootstrap
- nix-shell --pure --run "HOME=$(CURDIR) rebar3 do compile,dialyzer,eunit"
-
-
-
- If you add the shell.nix as described and
- user rebar as follows things should simply work.
-
-
-
-
-
- Generating Packages from Hex with Hex2Nix
-
- Updating the Hex packages requires the use of the
- hex2nix tool. Given the path to the Erlang
- modules (usually
- pkgs/development/erlang-modules). It will
- happily dump a file called
- hex-packages.nix. 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.
-
-
- 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 nixpkgs repository). that follows.
-
-
-$ nix-build -A erlangPackages
-
-
- That will build every package in
- erlangPackages. Then you can go through and
- manually remove the ones that fail. Hopefully, someone will
- improve hex2nix in the future to automate
- that.
-
-
-
diff --git a/doc/manual.xml b/doc/manual.xml
index de663fcd5b6..1045d0d4f81 100644
--- a/doc/manual.xml
+++ b/doc/manual.xml
@@ -21,7 +21,7 @@
-
+
diff --git a/pkgs/development/beam-modules/build-mix.nix b/pkgs/development/beam-modules/build-mix.nix
index 12efc00b050..70c186df8a0 100644
--- a/pkgs/development/beam-modules/build-mix.nix
+++ b/pkgs/development/beam-modules/build-mix.nix
@@ -8,7 +8,6 @@
, beamDeps ? []
, postPatch ? ""
, compilePorts ? false
-, installPhase ? null
, meta ? {}
, ... }@attrs:
diff --git a/pkgs/development/beam-modules/default.nix b/pkgs/development/beam-modules/default.nix
index 03bab8c4aa9..fec600400cb 100644
--- a/pkgs/development/beam-modules/default.nix
+++ b/pkgs/development/beam-modules/default.nix
@@ -12,6 +12,5 @@ let
## Non hex packages
hex = callPackage ./hex {};
webdriver = callPackage ./webdriver {};
- elli = callPackage ./elli {};
};
in self // self.hexPackages
diff --git a/pkgs/development/beam-modules/hex-registry-snapshot.nix b/pkgs/development/beam-modules/hex-registry-snapshot.nix
index 378fb382f95..3c2690c0103 100644
--- a/pkgs/development/beam-modules/hex-registry-snapshot.nix
+++ b/pkgs/development/beam-modules/hex-registry-snapshot.nix
@@ -2,14 +2,14 @@
stdenv.mkDerivation rec {
name = "hex-registry";
- rev = "329ae2b";
+ rev = "59b836d";
version = "0.0.0+build.${rev}";
src = fetchFromGitHub {
owner = "erlang-nix";
repo = "hex-pm-registry-snapshots";
inherit rev;
- sha256 = "1rs3z8psfvy10mzlfvkdzbflgikcnq08r38kfi0f8p5wvi8f8hmh";
+ sha256 = "1l8m6ckn5ivhfiv3k4dymi6b7wg511fwymnpxd6ymfd39dq0n5b0";
};
installPhase = ''
diff --git a/pkgs/development/tools/erlang/cuter/default.nix b/pkgs/development/tools/erlang/cuter/default.nix
index a8806127d35..7d05a56bfdf 100644
--- a/pkgs/development/tools/erlang/cuter/default.nix
+++ b/pkgs/development/tools/erlang/cuter/default.nix
@@ -1,5 +1,5 @@
{stdenv, autoconf, which, writeText, makeWrapper, fetchFromGitHub, erlang,
- erlangPackages, z3, python27 }:
+ beamPackages, z3, python27 }:
stdenv.mkDerivation rec {
name = "cuter";
@@ -13,9 +13,9 @@ stdenv.mkDerivation rec {
};
setupHook = writeText "setupHook.sh" ''
- addToSearchPath ERL_LIBS "$1/lib/erlang/lib/"
+ addToSearchPath ERL_LIBS "$1/lib/erlang/lib/"
'';
- buildInputs = with erlangPackages; [ autoconf erlang z3 python27 makeWrapper which ];
+ buildInputs = with beamPackages; [ autoconf erlang z3 python27 makeWrapper which ];
buildFlags = "PWD=$(out)/lib/erlang/lib/cuter-${version} cuter_target";
configurePhase = ''