[erlang-questions] Ability to add app directories explicitly for reltool
Dmitry Demeshchuk
demeshchuk@REDACTED
Sat Jan 14 11:21:17 CET 2012
Here's another story.
Again, I have a projects/ directory and tons of projects and libraries
in it (most of them totally independent on the current project I'm
trying to build).
projects/
proj1/
proj2/
....
proj118/
my_project/
What I want is to exclude them from my_project/ release package (for
obvious reasons). For now, the only way I see is to write in
reltool.config:
{incl_cond, exclude}
Which means, I'll have to explicitly set the applications to include
into the release. Okay, not a big deal, I can teach rebar to do that:
gather all the deps that are listed in rebar.config, for each of them
gather its dependencies too, and so on. Then, write explicit
{incl_cond, include} conditions for them
But wait, it's not working. Shoot, I have to set include conditions
for internal Erlang applications as well. Apparently, syntax_tools and
compiler are being used somewhere. And mochiweb is using crypto,
inets, ssl, and public_key.
But all I actually wanted to do here is just including my core
application, my_project/, into release, along with dependencies.
On Sat, Jan 14, 2012 at 2:10 PM, Dmitry Demeshchuk <demeshchuk@REDACTED> wrote:
> 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
--
Best regards,
Dmitry Demeshchuk
More information about the erlang-questions
mailing list