[erlang-questions] Ability to add app directories explicitly for reltool

Dmitry Demeshchuk <>
Sat Jan 14 11:10:04 CET 2012


Found another interesting problem with the approach we are discussing.

Say, I have a folder where all my projects reside:

projects/
    my_work_project/
    my_home_project/
    my_work_lib/
    my_home_lib/
    opensource_lib/

So, work project requires work lib and opensource lib, and home
project requires home lib and opensource lib:

projects/
    my_work_project/
        deps/
            my_work_lib/
            opensource_lib/
    my_home_project/
         deps/
            my_home_lib/
            opensource_lib/
    my_work_lib/
    my_home_lib/
    opensource_lib/


Now if I setup reltool.config, say, for the work project, like this:

{lib_dirs, ["projects/my_work_project/deps", "projects"]}.

during release package generation reltool will tell me:

{"init terminating in do_boot","my_work_lib: Application version
clash. Multiple directories contains version \"1.0\"."}

Because my_work_lib resides both in deps/ folder (cloned there by
rebar) and projects/ folder where I work on it.
And I will get the same error for opensource_lib.

The only workaround I see is to compile my_work_lib and opensource_lib
that reside in projects/ and manually remove them from deps/. This
way, they will reside in only one place and won't cause conflicts.

On Fri, Jan 13, 2012 at 8:20 PM, Dmitry Demeshchuk <> wrote:
> Also, answering your last question: no, I'm not expecting reltool to
> automatically include deps (but this is a thing to consider, maybe
> it's not bad). I expect to be able to add a certain app dir, so
> reltool.config from my previous example will be something like this:
>
> {lib_dirs, ["../deps"]}.
> {explicit_lib_dirs, [".."]}.
>
> Thank you.
>
> On Fri, Jan 13, 2012 at 8:18 PM, Dmitry Demeshchuk <> wrote:
>> Here's a more certain example.
>>
>> =========================================================================================
>>
>> Say, I clone some repository from GitHub (say, gproc, like in my
>> example gist). Now I add some stuff to it and want to build a release.
>> Here's how it should look:
>>
>> some_dir/
>>    gproc/
>>        src/
>>        include/
>>        ebin/
>>        priv/
>>        deps/
>>        rel/
>>           reltool.config
>>           files/      (this contains starting bash scripts, default
>> config file and so on)
>>           gproc/     (this directory will be actually generated by
>> rebar when running "rebar generate"; in fact, most of its content is
>> generated by reltool)
>>                erts-5.8.5/
>>                lib/
>>                priv/
>>                releases/
>>
>>
>> So, my release will run from "rel/gproc".
>>
>> Now, if I generate a release upgrade to release 2.0, I make some
>> changes, do "rebar generate-appups && rebar generate-upgrade" and a
>> new release package is created:
>>
>> rel/gproc/releases/gproc-2.0.tar.gz
>>
>> Then I just remsh to my running node and install the new release using
>> release_handler.
>>
>> ================================================================================
>>
>> What I want here is to be independent from the top-level folder
>> (some_dir). Maybe I have more Erlang projects there, maybe just some
>> pictures, books and MongoDB logs, it can be anything.
>>
>> For now, the only thing I can do without doing anything with directory
>> structure is adding to reltool.config this:
>>
>> {lib_dirs, ["../.."]}.
>>
>> or in an absolute way:
>>
>> {lib_dirs, ["/home/me/some/path/some_dir"]}.
>>
>>
>> Does this make sense?
>>
>> On Fri, Jan 13, 2012 at 7:56 PM, Siri Hansen <> wrote:
>>> Yes, we are definitely drifting away from the original problem. But I found
>>> it quite interesting also... :)
>>>
>>> Anyway - I'm not against introducing new functionality if it is needed - but
>>> I do believe in doing a good investigation in order to ensure (or at least
>>> attempt) the best possible solution. The problem for me was that I did not
>>> really understand the problem. I'm not sure if I still do (sorry!) - but
>>> I'll try to explain what I think you mean. Please correct me if (when) I'm
>>> wrong... ;)
>>>
>>> I think that what you suggest is to be able to point out one specific
>>> application directory instead of specifying one or more lib dirs. And the
>>> reason for this is that you have several applications stored under the same
>>> lib dir, which are not necessarily at all related to each other. And
>>> typically - for each core application (which forms the main functionality of
>>> a release), you have it's dependency applications stored in the deps
>>> directory under the core application itself. Is this correct?
>>>
>>> How do you handle different version of the core app and of the dep apps?
>>> Could you give an example of this? e.g.
>>>
>>> lib/
>>>    coreapp-1.0/
>>>       src/
>>>       ebin/
>>>       include/
>>>       priv/
>>>       deps/
>>>          app1-1.0/
>>>              src
>>>              ebin
>>>        ...
>>>    coreapp-2.0/
>>>       src/
>>>       ebin/
>>>       include/
>>>       priv/
>>>       deps/
>>>          app1-1.1/
>>>              src
>>>              ebin
>>>       ...
>>>
>>> And, when specifying the explicit app dir, would you expect reltool to
>>> automatically include the deps directory in the selected coreapp-Vsn as a
>>> lib dir?? Or should there be a way to specify that also?
>>>
>>> I hope I'm not totally on the wrong track here...
>>>
>>> /siri
>>>
>>>
>>> 2012/1/13 Dmitry Demeshchuk <>
>>>>
>>>> Hi, Siri.
>>>>
>>>> I guess, we are moving away from the main conversation.
>>>>
>>>> Don't you think that it would be good to make reltool do the required
>>>> job in a simpler way? The way we are discussing works in most cases,
>>>> but it's quite unclear for the people who aren't very familiar with
>>>> reltool.
>>>>
>>>> Using the existing functionalities to solve problems is often good,
>>>> but if the solution becomes complicated, maybe a new functionality
>>>> should be created instead.
>>>>
>>>> On Thu, Jan 12, 2012 at 6:47 PM, Siri Hansen <> wrote:
>>>> > Ah... this is interesting... a missing test case maybe - but I'm not
>>>> > sure if
>>>> > it is a bug.
>>>> >
>>>> > What happens is that the duplicated module erl_parse causes erlson to
>>>> > become
>>>> > derived since a module with the same name is used by stdlib and several
>>>> > other applications. If it was only stdlib, then I guess reltool could
>>>> > make
>>>> > the assumption that the module to use is the one in the same application
>>>> > and
>>>> > thus never make erlson derived (because to this module, that is).
>>>> > However,
>>>> > since the module in this case is also used by other applications, this
>>>> > assumption is not that obvious.
>>>> >
>>>> > The easiest way to get around this right now is to be more specific in
>>>> > the
>>>> > config file to make sure that erlson (or only the erl_parse module) is
>>>> > excluded... e.g. by adding
>>>> >
>>>> > {app, erlson, [{incl_cond,exclude}]} or
>>>> > {app, erlson, [{mod,erl_parse,[{incl_cond,exclude}]}]}
>>>> >
>>>> > (The latter would allow erlson to be derived if any of it's other
>>>> > modules
>>>> > were used by other applications)
>>>> >
>>>> > Regards
>>>> > /siri
>>>> >
>>>> > 2012/1/12 Dmitry Demeshchuk <>
>>>> >>
>>>> >> Try running this gist: https://gist.github.com/1600020
>>>> >>
>>>> >> reltool.config will reside in lib/gproc/rel/
>>>> >>
>>>> >> Thank you.
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Dmitry Demeshchuk
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Dmitry Demeshchuk
>
>
>
> --
> Best regards,
> Dmitry Demeshchuk



-- 
Best regards,
Dmitry Demeshchuk



More information about the erlang-questions mailing list