While you are developing it would be nice to be able to create a test release that has things like meck included, which only makes sense to have around for testing.

I know that I can just create another release in relx.config, but since the test release is a super set of the release I am about to create it would be nice if I could avoid "cloning" the release.

Would it be possible to create a new release by extending an existing one?
That would solve my problem and work well while developing.

Possible fixed by running release_handler:create_RELEASES/4

I'm now running relx 73536c5. With reference to beat 0c25d4f7aae25a3111b8971a7d029b845088ce5a, I find the following:

> sh v1to2.sh
...
Starting relx build process ...
Resolving OTP Applications from directories:
    /Users/blt/projects/us/troutwine/beat/apps
    /Users/blt/projects/us/troutwine/beat/deps
    /Users/blt/.kerl/installs/R15B03/lib

Resolving available releases from directories:
    /Users/blt/projects/us/troutwine/beat/apps
    /Users/blt/projects/us/troutwine/beat/deps
    /Users/blt/.kerl/installs/R15B03/lib

Resolved beat-0.1.0
release successfully created!
tarball /Users/blt/projects/us/troutwine/beat/_rel/beat-0.1.0.tar.gz successfully created!
Tarball generation error for error reason {case_clause,
                                           {"/Users/blt/projects/us/troutwine/beat/_rel/58639684/lib",
                                            {error,eexist}}}
Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

make: *** [release] Error 127

The command issued by the v1to2.sh script via the project Makefile is

relx release tar

ninenines/cowboy#608

Awhile ago, the example relx configuration file had an output_dir entry mentioned. However, the output_dir entry has never worked (whenever I have tried it). I noticed that output_dir seems to be missing from the example configuration files now. Can output_dir be added and working for the configuration to avoid making the ugly "_rel" directory name?

When application A has included_applications specifying application B, and application B depends on A, relx gets an error about a circular dependency. The solution is to remove application A from the dependencies of all included_applications before checking the dependencies of application A (i.e., the act of including these applications satisfies their dependency on application A). An example is https://gist.github.com/okeuday/fb0d80f50fc13dc5b674 .

Using included_applications is not common, however, it does provide a way of merging applications so that the included_applications become part of the main application's supervision hierarchy. The general use case for included_applications is when the included_applications are not real OTP applications, or if the included_applications need special source code for supervisor initialization (perhaps configuration related). In CloudI, the cloudi_core Erlang application is using included_applications to include various CloudI services, so that cloudi_core can start them within its supervision hierarchy based on configuration (dynamic configuration, or the configuration file read at startup).

In some cases you do not want to distribute the source code, so it would be nice if relx could create a release without the source.

I know that I can just tar up everything but the source files, but it is a bit annoying to have to do that.

This is the error I getting. I'd hate to go over many deps, fork them and fix .app.src files.

Resolved myrel-0.0.1
Errors generating release 
    someapp: Missing parameter in .app file: registered

According to Erlang/OTP documentation, many options in .app file have defaults, including registered, for which default is [].

http://www.erlang.org/doc/man/app.html

The README needs to be updated to include all the available options for the config file.

I have a an application that I'm trying to introduce relx into. Here's the pertinent portion of my relx.config (I've extracted the overlays):

{release,
 {fire_engine, "2013.12"},
 [
  fe_db
  , fe_tftp
  , fire_engine
  , fe_api
 ]
}.

{extended_start_script, true}.
{generate_start_script, false}.

Each sub-application has a .app defined in apps/APP_NAME/ebin/ but is otherwise typical for a rebar-driven project. I can generate a release well enough:

> relx
Starting relx build process ...
Resolving OTP Applications from directories:
    /Users/blt/projects/com/rackspace/fire_engine/apps
    /Users/blt/projects/com/rackspace/fire_engine/deps
    /Users/blt/.kerl/installs/R15B03/lib

Resolving available releases from directories:
    /Users/blt/projects/com/rackspace/fire_engine/apps
    /Users/blt/projects/com/rackspace/fire_engine/deps
    /Users/blt/.kerl/installs/R15B03/lib

Resolved fire_engine-2013.12
release successfully created!

I find that _rel/lib contains all the libraries it should:

> ls _rel/lib/                  
asn1-1.8           fire_engine-2013.1 kernel-2.15.3      ssh-2.1.2
bson-0             folsom-0.7.3       lager-1.2.0        ssl-5.1.1
compiler-4.8.2     gen_batch-1.0.2    mochiweb-1.5.1p3   stdlib-1.18.3
crypto-2.2         gen_script-1.0     mongodb-0.2.1      syntax_tools-1.6.9
eldap-1.0          ibrowse-3.0.4      public_key-0.17    webmachine-1.9.3
fe_api-2013.1      inets-5.9.2        rax_snmp-1.1.16
fe_db-2013.1       iron-0.0.1         sasl-2.2.1
fe_tftp-2013.1     jiffy-0.5.2        snmp-4.22.1

and that _rel/releases looks sensible:

> ls _rel/releases 
fire_engine-2013.12

After bumping the version in the fire_engine sub-application's app file to 2013.2, modifying relx.config to have a release target of 2013.13 and creating the following appup:

> cat apps/fire_engine/ebin/fire_engine.appup 
{"2013.2",
 [{"2013.1", [{load_module, fire_engine}]}],
 [{"2013.1", [{load_module, fire_engine}]}]
}.

I find that creating a relup is not so successful:

> relx relup
Starting relx build process ...
Resolving OTP Applications from directories:
    /Users/blt/projects/com/rackspace/fire_engine/apps
    /Users/blt/projects/com/rackspace/fire_engine/deps
    /Users/blt/.kerl/installs/R15B03/lib
    /Users/blt/projects/com/rackspace/fire_engine/_rel

Resolving available releases from directories:
    /Users/blt/projects/com/rackspace/fire_engine/apps
    /Users/blt/projects/com/rackspace/fire_engine/deps
    /Users/blt/.kerl/installs/R15B03/lib
    /Users/blt/projects/com/rackspace/fire_engine/_rel

Resolved fire_engine-2013.13
Errors generating release 
    fire_engine: File not found: "fire_engine.app"


Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

The relup was not generated, of course. Of particular concern is that _rel/lib/fire_engine-2013.1 has been deleted.

> ls _rel/lib  
asn1-1.8           fe_tftp-2013.1     jiffy-0.5.2        sasl-2.2.1
bson-0             folsom-0.7.3       kernel-2.15.3      snmp-4.22.1
compiler-4.8.2     gen_batch-1.0.2    lager-1.2.0        ssh-2.1.2
crypto-2.2         gen_script-1.0     mochiweb-1.5.1p3   ssl-5.1.1
eldap-1.0          ibrowse-3.0.4      mongodb-0.2.1      stdlib-1.18.3
fe_api-2013.1      inets-5.9.2        public_key-0.17    syntax_tools-1.6.9
fe_db-2013.1       iron-0.0.1         rax_snmp-1.1.16    webmachine-1.9.3

It seems that only the fire_engine sub-application was lost.

Problem summary:

• creating a relup failed unexpectedly and
• relup creation destroyed library required by a previously generated release.

I'd be happy to share any more information that might be useful. The project is proprietary but, if desired, I could try to make a minimal reproducing project and open-source that.

Why nodetool script include only when include_erts is true?

I have installed erlang and want generate release without it and with extended start scripts. But extended start script use nodetool that not included.

We ran across a bug where a dependency had tagged a commit causing the version to be returned as {vsn, v0.7.0} (piqi for those interested).

Relx depends on erlware commons ec_semver to parse out the version of the release which also strips out the v.

As below:

2> ec_semver:parse(<<"v0.7.0">>).
{{0,7,0},{[],[]}}

Resist the temptation to take pride in complexity.

Hello again,

I have a wish similar to #25 : making beautifull releases withOUT erts but with start/attach/stop scripts.
In short having both {include_erts, false} and {generate_start_script, true} or {extended_start_script, true}.
It seems to me that the "stop" script relies on "nodetool" which "relies on being in the erts bin dir".
If I understand well rlx_prv_assembler.erl the erts bin dir requirement is at least (at most?) for epmd_path(). I don't understand why nodetool {ping|stop|restart|reboot} does not assume epmd is already running and needs a way for a path to start epmd. I don't see start/attach/stop scripts as epmd monitors (systemd should be better at this I think).

Wild related suggestions :
a) patching nodetool or experimenting a nodetool2 ? commenting out "ok = start_epmd()," in rlx_prv_assembler.erl:1114
b) using ROOTDIR instead of BINDIR to put nodetool in the release tree :
NODETOOL="$BINDIR/escript $ROOTDIR/nodetool $NAME_ARG $COOKIE_ARG"
instead of
NODETOOL="$BINDIR/escript $BINDIR/nodetool $NAME_ARG $COOKIE_ARG"
c) looking for start&attach. Not relying on nodetool ?

Hopefully no one will be hurt by my confusion ;-)
It all started with a simple goal of start/stop a light release.

Have fun

What's the currently recommended way? Using rebar?

I'm trying to use relx on a cross-compiled project. I.e. I build on x86 and run on arm. By default relx uses the host (x86) system lib directory (found using code:lib_dir/0). I'd like relx to reference the arm version instead so that it will copy the arm shared libraries over instead of the x86 ones.

Using --default-libs=false, I can specify all lib dirs manually. That's what I'm doing now and relx works great. However, relx figures out all of the other default lib directories correctly, so it would be nice if I could just override the system lib directory. (--system-lib=?)

Also, while looking through the relx code, I saw relx_state:get/3 with discover_exclude_system in rlx_prv_discover.erl. This looked like an alternative to the above that would work for me, but I wasn't sure how to get discover_exclude_system set in the relx_state without code modifications.

Any other suggestions would be appreciated too.

Thanks

Currently in the source code, there is a logic to detect the default release when none is specified. However, it does not work as expected. I have attempted a fix but as the code comments are also outdated, I have decided to open an issue.

The current code does sort the releases but sorts them in ascending order:

https://github.com/erlware/relx/blob/master/src/rlx_prv_release.erl#L131

The code comment says they are supposed to be sorted in descending order though:

https://github.com/erlware/relx/blob/master/src/rlx_prv_release.erl#L114

Besides, this code comment says we should abort when the release names are different:

https://github.com/erlware/relx/blob/master/src/rlx_prv_release.erl#L133-L136

But the code behaves differently.

Currently if relcool is unable to find a dependency you receive the following error message (in this example sgte is missing):

Failed to solve release:
 Dependency sgte is specified as a dependency but is not reachable by the system.

It would be useful if this error message also specified the app the dep was declared:

Failed to solve release:
 Dependency sgte is specified as a dependency of maru_web but is not reachable by the system.

And it would be awesome to color code errors. And even better if sgte and maru_web were different colors or bold or with a format like:

Failed to solve release dependencies:

Dep: sgte
App: maru_web
Error: unable to resolve dependency

Which you could imagine if the error is that its the wrong version or some other problem it could be more descriptive.

It is not an issue.

If I used mnesia in my application, I need to figure out the db path when starting the server. e.g.

!/bin/sh

erl -pa ebin deps/*/ebin -mnesia dir '"db"'

How to handle it in relx?

Thanks in advance.

Using latest released relx:

===> Resolved screenshooter-1
escript: exception error: no function clause matching 
                 systools_make:'-format_error/1-fun-1-'({{yaml_schema_ruby,
                                                          yamler,
                                                          "/root/sauspiel-screenshooter/_rel/lib/yamler-1/ebin"},
                                                         {yaml_schema_ruby,
                                                          screenshooter,
                                                          "/root/sauspiel-screenshooter/_rel/lib/screenshooter-1/ebin"}}) (systools_make.erl, line 2215)
  in function  lists:map/2 (lists.erl, line 1224)
  in call from systools_make:format_error/1 (systools_make.erl, line 2215)
  in call from rlx_prv_assembler:format_error/1 (src/rlx_prv_assembler.erl, line 110)
  in call from relx:format_error/1 (src/relx.erl, line 217)
  in call from relx:report_error/2 (src/relx.erl, line 298)
  in call from relx:handle_output/3 (src/relx.erl, line 249)
  in call from relx:main/1 (src/relx.erl, line 60)

Using https://github.com/MSch/yamler

My app.src is pretty easy:

{application, screenshooter, [
  {description, "Sauspiel Screenshooter"},
  {vsn, "1"},
  {modules, []},
  {registered, []},
  {applications, [
    kernel,
    stdlib,
    cowboy,
    gproc,
    hackney,
    lager,
    mochijson2,
    yamler
  ]},
  {mod, {scsh_app, []}},
  {env, []}
]}.

Any ideas?

Using the following script--called v1to2.sh--in the root of the beat project:

#!/bin/sh                                                                               
## Run from the root of http://github.com/blt/beat

set -e

rm -rf /tmp/beat
rm -rf _rel

git checkout v1
make release
tar cvzf beat-0.1.0.tar.gz -C _rel .

git checkout v2
make relup
tar cvzf beat-0.1.1.tar.gz -C _rel .

mkdir -p /tmp/beat
cp beat-0.1.0.tar.gz /tmp
cp beat-0.1.1.tar.gz /tmp

cd /tmp/beat
tar xf /tmp/beat-0.1.0.tar.gz
./bin/beat-0.1.0 start

cp /tmp/beat-0.1.1.tar.gz releases/

I'm able to get a running release of beat-0.1.0 easily enough.

> ./bin/beat-0.1.0 start

> ./bin/beat-0.1.0 attach
([email protected])1> application:which_applications().
[{sasl,"SASL  CXC 138 11","2.2.1"},
 {beat_tcp_api,"The TCP API of the 'beat' project","2013.1"},
 {beat_core,"The core application of the 'beat' project'",
            "2013.1"},
 {stdlib,"ERTS  CXC 138 10","1.18.3"},
 {kernel,"ERTS  CXC 138 10","2.15.3"}]

When I attempt to unpack the release I find:

([email protected])2> release_handler:unpack_release("beat-0.1.1").
{error,{{badmatch,{error,enoent}},
        [{erl_tar,default_options,0,
                  [{file,"erl_tar.erl"},{line,440}]},
         {erl_tar,extract_opts,1,[{file,"erl_tar.erl"},{line,434}]},
         {erl_tar,extract,2,[{file,"erl_tar.erl"},{line,136}]},
         {release_handler,do_unpack_release,4,
                          [{file,"release_handler.erl"},{line,834}]},
         {release_handler,handle_call,3,
                          [{file,"release_handler.erl"},{line,588}]},
         {gen_server,handle_msg,5,
                     [{file,"gen_server.erl"},{line,588}]},
         {proc_lib,init_p_do_apply,3,
                   [{file,"proc_lib.erl"},{line,227}]}]}}

On #erlang @tsloughter was kind enough to look into my original report and indicated he had some success:

17:21 tristan__: troutwine: yea, so I got it to unpack properly
17:22 tristan__: but I had to place the beat.rel file with it under /tmp/beat/releases/2013.2
17:22 tristan__: then
17:22 vinoski: paatus: sure. the [ ... || ... ] construct is called a list comprehension. the D on the right gets each member of the list created by integer_to_list, and in turn each D is processed on the left
17:22 tristan__: release_handler:unpack_release("2013.2/beat").
17:22 tristan__: worked

I was not able to reproduce before @tsloughter had to leave the channel. (It may also be that @tsloughter was working from an old beat checkout. As of 6fcf9724cc8c9c247f1515d9b44b475b46a82e38 beat now uses semvar for release-level version numbers.)

Executing the generated bin script with the console_clean argument fails with the following error (edited to remove the absolute path prefix):

Exec: _rel/erts-5.10.4/bin/erlexec -boot _rel/releases/0.1.0-alpha/start_clean -mode embedded -config _rel/releases/0.1.0-alpha/sys.config -args_file _rel/releases/0.1.0-alpha/vm.args -- console_clean
Root: _rel
{"init terminating in do_boot",{'cannot get bootfile','_rel/releases/0.1.0-alpha/start_clean.boot'}}

Rebar supports that when git is supplied as vs ie.:
when {vsn, git} as the version in your .app.src, rebar will get the version string from the closest git tag.
I knwo taht this is not OTP standard practice, bu since lots of people are using rebar at the moment and there are repos that already follow this path. It will be great if this can be added. If you feel that this is not a standard otp practice, please provide an "upgrade" tool to do this.
This will help erlang muc more enterprise friendly as they are very big in release management, where Erlang is weak on.

Thanks

Sometimes it's necessary to run some installation code before starting a release. It would be great if relx included support for a setup target in the generated start script. This would in fact be similar to https://github.com/uwiger/setup

To reproduce, download the tar.gz from http://relx.org/ and extract. At the time that I did this, the files were extracted to erlware-relx-37bd98a/... Enter the directory and type "make". Eventually it will get to this error:

==> erlware-relx-37bd98a (compile)
src/rlx_provider.erl:36: can't find include lib "relx/include/relx.hrl"

If I rename "erlware-relx-37bd98a" to "relx" and run "make" again, everything compiles successfully.

I'm not sure what the preferred way would be for fixing this or I'd submit a patch.

I'd like to make a feature request to add an option to generate the *.rel file only (and optionally compile it into *.boot) without generating any other files.

This may be needed if one wishes during development not to run a node using embedded startup, but rather to allow starting a node using the boot script from command line having a rather simple directory layout (ebin/, src/, priv/*).

extended start script uses erlexec without any hints where to get it

would be nice to have something like

relx tar --include-only-changed-apps

In my application I have a "priv" dir containing subdirectories that I want to be packaged into the application.

As I see it, rebar supports copying directories via overlay while relx does not.

In Rebar, a common use by me is to override sys.config through an overlay_vars directive. I then set this up so I have a proper release and a "development release" based upon which overlay vars have been set.

There seem to be no way to do this in relx. Specifically:

• A way to say that the sys.config file is a template ripe for substitution.
• A way to specify that I want to override overlay_vars on the command line.

How do you propose one solves this? For now, I have resorted to having multiple releases and to run the sys.config substitution before relx from GMake. Is this the right way to approach the problem, now we do have a substitution framework in place?

I think I have a gist of what is wrong.

In rlx_prv_assembler:remove_symlink_or_directory/1 the apps under _rel/lib are all deleted.

I guess that relx has decided to look for the apps in those directories and then they are removed under its feets.

The funny thing is that the app from .. handles this. It is there all the time and it gets deleted just fine and then regenerated.

For now I will just create a makefile that removes _rel/lib before running relx.

Cheers,
__

In dev_mode relx properly creates a symlink to the sys config file defined with sys_config in the config file. But it crashes on any run after the first because it tries to create that link again and doesn't properly handle a failure for it already existing.

Relx fails to build a release, because I have a non-Erlang dependency without ebin folder or with empty ebin folder.
Like this one:
https://github.com/basho/node_package

There is also something called rebar raw dependencies [1] and I believe that more correct behaviour for Relx is either copy them to release or ignore them, but not to fail release creation altogether.

basho/rebar#217 (comment)

$ ./relx
Starting relx build process ...
Resolving OTP Applications from directories:
    /home/me/ws/myproject/lib
    /home/me/ws/myproject/deps
    /usr/local/lib/erlang/lib

no beam files found in directory /home/me/ws/myproject/deps/node_package/ebin

Usage: relx [-n <relname>] [-v <relvsn>] [-g <goal>] [-u <upfrom>]
            [-o <output_dir>] [-l <lib_dir>]
            [--disable-default-libs [<disable_default_libs>]]
            [-V [<log_level>]] [-a <override_app>] [-c [<config>]]
            [-r <root_dir>] [*release-specification-file*]

  -n, --relname           Specify the name for the release that will be 
                          generated
  -v, --relvsn            Specify the version for the release
  -g, --goal              Specify a target constraint on the system. These 
                          are usually the OTP
  -u, --upfrom            Only valid with relup target, specify the 
                          release to upgrade from
  -o, --output-dir        The output directory for the release. This is 
                          `./` by default.
  -l, --lib-dir           Additional dirs that should be searched for OTP 
                          Apps
  --disable-default-libs  Disable the default system added lib dirs (means 
                          you must add them all manually [default: false]
  -V, --verbose           Verbosity level, maybe between 0 and 2 [default: 
                          1]
  -a, --override_app      Provide an app name and a directory to override 
                          in the form <appname>:<app directory>
  -c, --config            The path to a config file [default: ]
  -r, --root              The project root directory

$ 

Hello,

I'm new to relx. It seems cool. Thanks.
I've {include_src, false}. in my relx config.
After building the release the "src" directory and its content are not included as expected.
I have also {i, "include"} in erl_opts in rebar.config . After building the release the "include" directory and its source content is packaged in the release. I didn't expect that as I think included src is src.
Is this an issue with {include_src, false} ?

Have fun

As I read the rel documentation one can either omit the mod key or give it as {mod, []} when there is nothing that has to be started in an application. I could be misreading it.

Currently relx only works when mod is omitted.

For {foo, undefined} overlay variable relx produces {foo, } causing the release fail to start due to syntax error. Is there a workaround for this?

It should actually probably be --default-libs false instead. The default value for default-libs should be true and you pass false to disable them.

Hello,

remote_console doesn't work due some incorrect paths.

Regards.

With dev_mode set to true I discovered release creation was extremely slow compared to with it false. I ran with -V3 and saw that it was resolving dozens of the same release (the one I'm working on) when it should be 1. I'm guessing an issue with symlinks.

If the vm.args file is found in releases/appname-ver/, it will create a log/ directory in there instead of doing so in the base directory as expected.

You probably want RUNNER_LOG_DIR=$USE_DIR/log to not use $USE_DIR there.

When I build a release I get:

===> Unable to read vars file (./acdefgilnorsv) for overlay due to: enoent

A known good commit: 37bd98a

Using relx eb6a468:

> relx
Starting relx build process ...
Resolving OTP Applications from directories:
    /Users/blt/projects/com/rackspace/fire_engine/apps
    /Users/blt/projects/com/rackspace/fire_engine/lib
    /Users/blt/.kerl/installs/R15B03/lib
    /Users/blt/projects/com/rackspace/fire_engine/_rel


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18591.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{lists,map... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18655.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{ec_plists... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18670.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{lists,map... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18685.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{ec_plists... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18674.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{lists,map... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18699.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{lists,map... 


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Too many processes


=ERROR REPORT==== 14-Aug-2013::12:33:10 ===
Error in process <0.18692.0> with exit value: {system_limit,[{erlang,spawn_opt,[{erlang,apply,[#Fun<ec_plists.42.48025292>,[]],[monitor]}],[]},{erlang,spawn_monitor,1,[]},{ec_plists,'-local_runmany/3-fun-1-',3,[{file,"src/ec_plists.erl"},{line,739}]},{lists,map,2,[{file,"lists.erl"},{line,1173}]},{lists,map... 

escript: exception exit: {system_limit,
                    [{erlang,spawn_opt,
                         [{erlang,apply,
                              [#Fun<ec_plists.42.48025292>,[]],
                              [monitor]}],
                         []},
                     {erlang,spawn_monitor,1,[]},
                     {ec_plists,'-local_runmany/3-fun-1-',3,
                         [{file,"src/ec_plists.erl"},{line,739}]},
                     {lists,map,2,[{file,"lists.erl"},{line,1173}]},
                     {lists,map,2,[{file,"lists.erl"},{line,1173}]},
                     {ec_plists,local_runmany,3,
                         [{file,"src/ec_plists.erl"},{line,735}]},
                     {lists,map,2,[{file,"lists.erl"},{line,1173}]},
                     {ec_plists,'-local_runmany/3-fun-0-',3,
                         [{file,"src/ec_plists.erl"},{line,737}]}]}
  in function  ec_plists:handle_error/3 (src/ec_plists.erl, line 884)
  in call from ec_plists:local_runmany/3 (src/ec_plists.erl, line 748)
  in call from rlx_dscv_util:do/2 (src/rlx_dscv_util.erl, line 52)
  in call from rlx_app_discovery:resolve_app_metadata/2 (src/rlx_app_discovery.erl, line 56)
  in call from rlx_prv_discover:do/1 (src/rlx_prv_discover.erl, line 46)
  in call from relx:run_provider/2 (src/relx.erl, line 254)
  in call from lists:foldl/3 (lists.erl, line 1197)
  in call from relx:run_providers/1 (src/relx.erl, line 242)

in the project root I've got the following relx.config

{release,
 {fire_engine, "2013.11"},
 [
  fe_db,
  fe_tftp,
  fire_engine,
  fe_api
 ]
}.

The project uses rebar as its build tool. Each of the applications listed in relx.config are stored under project root apps/ and are OTP applications.

There are no symbolic links up the directory tree and no overlays which create any.

Project rebar.configs follow. fe_tftp and fe_db have no rebar.config of their own.

rebar.config

%% -*- tab-width: 4;erlang-indent-level: 4;indent-tabs-mode: nil -*-
%% ex: ts=4 sw=4 ft=erlang et

%% == Core ==

%% Additional library directories to add to the code path
{lib_dirs, ["apps"]}.

%% == Erlang Compiler ==

{erl_opts, [
        debug_info,
        warn_obsolete_guard,
        warn_unused_import,
        warn_shadow_vars,
        warn_export_vars,
        warn_export_all,
        {parse_transform, lager_transform}
    ]}.

%% == Dependancies ==

{deps_dir, ["lib"]}.

{deps, [
    % Parse transform libraries have to come first.
    {lager,        ".*", {git, "git://github.com/basho/lager.git",                {tag, "1.2.0"}}},
    % Remaining libraries are not particularly ordered.
    {gen_script,   ".*", {git, "git://github.com/rackerlabs/gen_script.git",      {tag, "1.0"}}},
    {gen_batch,    ".*", {git, "git://github.rackspace.com/fdaat/gen_batch.git",  {tag, "1.0.2"}}},
    {rax_snmp,     ".*", {git, "git://github.rackspace.com/fdaat/rax_snmp.git",   {tag, "1.1.16"}}},
    {webmachine,   ".*", {git, "git://github.com/basho/webmachine.git",           {tag, "1.9.3"}}},
    {jiffy,        ".*", {git, "git://github.com/davisp/jiffy.git",               {tag, "0.5.2"}}},
    {ibrowse,      ".*", {git, "git://github.com/cmullaparthi/ibrowse.git",       {tag, "v3.0.4"}}},
    {appstart,     ".*", {git, "git://github.com/hyperthunk/appstart.git",        {tag, "0.0.3"}}},
    {meck,         ".*", {git, "git://github.com/eproxus/meck.git",               {tag, "0.7.2"}}},
    {folsom,       ".*", {git, "git://github.com/boundary/folsom.git",            {tag, "0.7.3"}}},
    {mochiweb,     ".*", {git, "git://github.com/basho/mochiweb",                 {tag, "1.5.1p3"}}},
    % These projects do not have version tags in their repos
    {props,        ".*", {git, "https://github.com/greyarea/props.git",           {tag, "3e1c0a1e"}}},
    {bson,         ".*", {git, "git://github.com/mongodb/bson-erlang.git",        {tag, "17373ef4"}}},
    {mongodb,      ".*", {git, "git://github.com/mongodb/mongodb-erlang.git",     {tag, "bc41adb0"}}},
    {sync,         ".*", {git, "git://github.com/rustyio/sync.git",               {tag, "6a28ff97"}}},
    {iron,         ".*", {git, "git://github.com/elementerl/iron.git",            {tag, "50a6d699"}}},
    {updo,         ".*", {git, "git://github.com/dergraf/updo.git",               {tag, "75f089f5"}}}
]}.

%% == Subdirectories ==

{sub_dirs, ["apps/fe_db", "apps/fire_engine", "apps/fe_api", "apps/fe_tftp", "rel"]}.

%% == xref ==

{xref_warnings, false}.
{xref_checks,   [undefined_function_calls, deprecated_function_calls]}.

apps/fire_engine/rebar.config

{erl_opts, [
            debug_info,
            warn_obsolete_guard,
            warn_unused_import,
            warn_shadow_vars,
            warn_export_vars,
            warn_export_all,
            warnings_as_errors,
            {parse_transform, lager_transform}
           ]}.

%% == Cover ==

{cover_enabled, true}.
{cover_export_enabled, true}.

%% == Common Test ==

{ct_dir, "itest"}.
{ct_extra_params, "-config ../../etc/private.config"}.

%% == Cleanup ==

{clean_files, ["itest/*.beam"]}.

apps/fe_api/rebar.config

%% == Cover ==

{cover_enabled, true}.
{cover_export_enabled, true}.

%% == Common Test ==

{ct_dir, "itest"}.
{ct_extra_params, "-config ../../etc/private.config -pa ../fire_engine/ebin"}.

%% == Cleanup ==

{clean_files, ["itest/*.beam"]}.

Currently only one file is able to be set to contain variables for overlays. Like:

{overlay_vars, "vars.config"}.

It would be good to be able to support multiple files. This way if you have multiple releases that should share some set of global overrides you can separate that into a file.

{overlay_vars, ["vars1.config", "vars2.config"]}.

I'm at the cargo cult stage, so I don't understand what went wrong here. After the failure, on a whim, I cd'd into deps/erlware_commons and ran "make", which claimed to run successfully to completion, then cd'd ../.. and ran make again, which did not report an error. I've no idea if I've laid a landmine for myself...

bash-4.2$ make
/usr/bin/rebar get-deps
==> neotoma-1.6.0 (get-deps)
==> erlydtl-0.6.0 (get-deps)
==> getopt-0.7.0 (get-deps)
==> relx (get-deps)
Pulling rebar_vsn_plugin from {git,"https://github.com/erlware/rebar_vsn_plugin.git",
{tag,"master"}}
Cloning into 'rebar_vsn_plugin'...
Pulling erlware_commons from {git,"https://github.com/erlware/erlware_commons.git",
{branch,"master"}}
Cloning into 'erlware_commons'...
==> rebar_vsn_plugin (get-deps)
==> erlware_commons (get-deps)
/usr/bin/rebar compile
==> rebar_vsn_plugin (compile)
Compiled src/rebar_vsn_plugin.erl
==> neotoma-1.6.0 (compile)
==> neotoma-1.6.0 (post_compile)
==> erlware_commons (compile)
Compiled src/ec_dictionary.erl
Compiled src/ec_rbdict.erl
Compiled src/ec_lists.erl
Compiled src/ec_dict.erl
Compiled src/ec_gb_trees.erl
Compiled src/ec_file.erl
Compiled src/ec_semver.erl
Compiled src/ec_orddict.erl
Compiled src/ec_talk.erl
Compiled src/ec_compile.erl
Compiled src/ec_semver_parser.erl
Compiled src/ec_assoc_list.erl
Compiled src/ec_plists.erl
Compiled src/ec_date.erl
==> erlware_commons (post_compile)
==> erlydtl-0.6.0 (compile)
ERROR: One or more modules listed in erlydtl.app are not present in ebin/.beam:
* gettext
ERROR: compile failed while processing /usr/lib64/erlang/lib/erlydtl-0.6.0: rebar_abort
make: ** [deps] Error 1

Overriding release/{{rel}}/vm.args does not seem possible since overlays are executed after rcl_prv_assembler.

Following patch will add a {vm_args, _} option to relcool.config, i have not made a pull req since I think this could be solved in multiple ways:

• Allowing to override the arguments used when calling release from _rel/bin/*
• Reorder assemblers to make overlay run last
• Use patch above

2:05 < evax> I'm realizing overlays are not honored in tar files
02:06 < evax> because of the use of systools:make_tar
02:06 < evax> that is they're in rel/ but not in the tar file
02:06 < evax> shouldn't we drop systools:make_tar alltogether?
08:45 < tristan_> no. and do you mean like dirs createf with overlays?
08:46 < tristan__> i'm off for a bit but can talk abpu this later
09:54 < tristan__> evax: so regarding using make_tar, make_tar does numerous things that not done exactly will
fuck up use with systools to install/unpack/upgrade releases
09:54 < tristan__> instead of copying that to relx I simply use make_tar and then add tothe tar what we want to
additionally include
09:55 < tristan__> which I guess I forgot to include any files/dirs created by templates
10:06 < wilberine> so is this a bug? or just a new feature we need to add?
10:07 < tristan__> both
10:07 < tristan__> I'd consider it a bug
10:10 < wilberine> ok, I will make an issue for it

Hi,

https://aur.archlinux.org/packages/relx/
https://github.com/AeroNotix/relx-pkgbuild

Hope that helps,
Aaron