[erlang-questions] Ability to add app directories explicitly for reltool
Dmitry Demeshchuk
demeshchuk@REDACTED
Mon Jan 16 12:14:37 CET 2012
On Mon, Jan 16, 2012 at 2:16 PM, Siri Hansen <erlangsiri@REDACTED> wrote:
> Ok, I get it :) We need a way to specify one explicit directory for an
> application!! Possible syntax:
>
> 1) On sys level: {explicit_app_dirs, [App1Dir]}
> or
> 2) On app level: {app,App1Name,[{incl_cond,include},{lib_dir,App1Dir}]}
>
> Any preference?? (I think I like the latter - but is there any reason not to
> have this on app level?)
Yes, the second one seems more solid. After all, what we really care
about is applications list, not directories list.
>
> Maybe also let reltool search for multiple App1Dirs that are suffixed with
> -Vsn (if basename(App1Dir)=:=App1Name) - and pick the latest??
Nice idea. In that case I'd go further and parse app versions out of
the .app files and don't bind to the directory names. Also, maybe it's
good to silently ignore applications with same versions and just add a
single instance.
>
> /siri
>
>
>
> 2012/1/14 Dmitry Demeshchuk <demeshchuk@REDACTED>
>>
>> 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
>
>
--
Best regards,
Dmitry Demeshchuk
More information about the erlang-questions
mailing list