From be5da0449e4d9ce9bb68b7a3eaf099155accf64b Mon Sep 17 00:00:00 2001 From: Eric Merritt Date: Wed, 30 Mar 2016 10:17:59 -0700 Subject: [PATCH] beam-support: update registry to latest '59b836d' --- doc/beam-users-guide.xml | 376 ++++++++++++++++++ doc/erlang-users-guide.xml | 305 -------------- doc/manual.xml | 2 +- pkgs/development/beam-modules/build-mix.nix | 1 - pkgs/development/beam-modules/default.nix | 1 - .../beam-modules/hex-registry-snapshot.nix | 4 +- .../tools/erlang/cuter/default.nix | 6 +- 7 files changed, 382 insertions(+), 313 deletions(-) create mode 100644 doc/beam-users-guide.xml delete mode 100644 doc/erlang-users-guide.xml 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 = ''