[erlang-questions] Ability to add app directories explicitly for reltool
Dmitry Demeshchuk
demeshchuk@REDACTED
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 <demeshchuk@REDACTED> 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 <demeshchuk@REDACTED> 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 <erlangsiri@REDACTED> 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 <demeshchuk@REDACTED>
>>>>
>>>> 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 <erlangsiri@REDACTED> 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 <demeshchuk@REDACTED>
>>>> >>
>>>> >> 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