Ulf Wiger ulf.wiger at erlang-solutions.com
Mon Mar 8 11:13:34 EST 2010

David Smith wrote:
> On Sat, Mar 6, 2010 at 9:10 AM, Ulf Wiger 
> <ulf.wiger at erlang-solutions.com <mailto:ulf.wiger at erlang-solutions.com>> 
> wrote:
>     I played with one version of this in 'builder', where the core
>     idea was to build a boot script for each application (and place
>     it in the priv/ directory). Builder would generate the .app
>     file and a boot script based on a set of directives in a
>     <App>/BUILD_OPTIONS file. Among other things, it would list
>     the applications needed in the boot script; if no version was
>     given, 'builder' would locate the latest version.
> This would be quite trivial w/ rebar. What's not clear to me is whether 
> the expectation is that apps will be installed in the erlang/lib 
> directory or...?

Perhaps I'll be showing my age here, and I must confess I'm not
as up-to-speed on what Reltool provides, so some of this might
in fact be obsolete nowadays. :)

Having worked in large organizations where getting root access
on your unix box is near-impossible, and the Erlang/OTP code
sits on a file server used by hundreds of people, I've gotten
used to _never_ installing any of my own apps under the OTP
lib root. Also, in the products I worked on at Ericsson, we
preferred to keep our own apps and OTP's separate. This is not
a problem for systools. You can have lots of different lib roots

>     In another setting, we've played with a system configuration
>     file, where you can have options like {apps, [App]}, and
>     {env, App, [{Key, Val}]} options. From this, a script builds
>     a .rel file a sys.config and a start.boot. By changing the
>     .rel file so that all apps are made load-only, except stdlib,
>     kernel and a special 'setup' app, an installation boot script
>     can be auto-generated too. It allows you to start an erlang VM
>     with all the paths set and all the apps loaded, with proper
>     environment settings. The setup app then looks for '$setup'
>     hooks* (as env variables) in all loaded app files, calls them
>     in order, thus getting all the needed install, database
>     schema etc. in place.
> This one is a bit more complex, but rebar could still facilitate. 
> Personally, I'm not sure I buy into the value of running apps within a 
> single Erlang instance. I prefer the self-contained install so as to 
> avoid surprises when versions of things change, and for the convenience 
> of deployment. However, given the interest, if we can come up with a 
> good, standard way of attacking this, I'm ok with adding support to rebar. 

But in large and complex systems, you will often end up with apps
that are loosely coupled components. They need to be kept separate
for various reasons (diverging requirements, reuse, separate
design teams), but need to run in the same VM for performance
reasons. Often, the different components aren't self-contained,
in the way that e.g. riak and webmachine are, but depend critically
on each other and must run together for the system to work
(if not in the same VM, at least in the same cluster).

> Ulf, Andrew, Tuncer -- can you guys come up with a standard way of 
> attacking this and sketch out what support rebar would need to provide? 
> I like the idea of dropping the .boot file into priv/ thus keeping apps 
> fairly self-contained. Dynamically selecting version numbers probably 
> should be a part of this as well -- if no specific vsn is given, use the 
> one on the Erlang path.
> I'm going to be traveling out to John Hopkins this week and then 1st 
> round of chemo on Friday, so I'll be available interstially. But let's 
> keep this ball rolling on the list and I'll do my best to chime in. :)

Best of luck with the treatment. Hope to see you back in action

Ulf W
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd



Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.


More information about the rebar mailing list