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

Dmitry Demeshchuk demeshchuk@REDACTED
Wed Jan 11 16:52:54 CET 2012


Hi, Siri!

Sorry for the long delay, I missed your e-mail and knew that you
replied only today. :(

As far as I understood your proposal, you suggest to use a directory
that contains Erlang our projects as a lib directory. It's a good
option, and perhaps we'll really use it instead of making some custom
stuff or asking you to patch reltool.

The only possible problem I can see is that any projects that cause
conflicts in reltool will make us unable to build release packages for
*the rest* of the projects that reside in the same directory.

Say, I had erlson in my projects directory, and it was causing the
conflicts during release package generation (well, placing
erl_parse.erl into application listing is wrong, it definitely needs
to be fixed).
Probably, the same goes to projects that may contain same modules in
the applications listing (rabbitmq and riak_core both use
gen_server2.erl, and those modules are actually different; this
doesn't affect any of them but definitely but won't let us build
release package).
Maybe, there are some more rare errors that might occur as well.

On the other hand, it's a good idea to make every project capable of
being built using reltool, and this problem may serve as a good
indicator of the projects that need to be improved.

I'm not even sure that I want to continue making the initial request.
:) It's definitely not bad (at least because of the fact that the
proposed solution wasn't that obvious), but on the other hand stubborn
people will eventually come up with a decent solution, by thinking or
searching.

Thank you.

On Thu, Dec 29, 2011 at 5:55 PM, Siri Hansen <erlangsiri@REDACTED> wrote:
> Hi Dmitry!
>
> At the first glance I find Garret's proposal very good. I find it reasonable
> to have the dependency applications outside of the core application, since
> different core applications might share the same dependencies.
>
> However, if your directory structure is the most common way, I assume it
> would be a good idea if reltool could support it.
>
> Now I have the feeling that I missed something important, but why can't you
> have your structure
>
> lib/coreapp/
>    deps/
>    ebin/
>    include/
>    priv/
>    src/
>
> and give the following to reltool:
>
> [{lib_dirs, ["lib", "lib/coreapp/deps"]}...]
>
> ??
>
> That would create a target with both your coreapp and the apps in the deps
> directory....
>
> Regards
> /siri
>
>
> 2011/12/22 Dmitry Demeshchuk <demeshchuk@REDACTED>
>>
>> Hi, Garret.
>>
>> Thanks, didn't think about the problem this way. This is much easier
>> than making a rebar plugin :)
>>
>> Still, it clearly seems like a workaround too.
>> Generally, you have one core application and multiple dependencies in
>> a project, or at least so tells me my experience. These dependencies
>> may be either independent applications (gproc, gen_bunny or whatever)
>> or module libraries. (Of course, there are some exceptions of such a
>> scheme, modern Riak for example, but there aren't many of them)
>> And this is exactly why most of the open-source projects have the same
>> directory structure as I described in my first email. Putting source
>> code into another directory is not a big deal, of course, but it's
>> slightly less convenient and more confusing.
>>
>> We can force these projects to do "git mkdir && git mv && git commit"
>> (not a big deal, would take less than a minute), or even to do nothing
>> (how many people like and use OTP upgrades?). Or we can add to reltool
>> an ability to understand their projects structure, and structure of
>> future 1000 projects.
>>
>> On Tue, Dec 20, 2011 at 11:25 PM, Garret Smith <garret.smith@REDACTED>
>> wrote:
>> > My rebar/reltool setup is doing close to what you describe as the
>> > "ideal"
>> > way.
>> >
>> > Relevant project structure is:
>> >
>> > apps/
>> >     app1
>> >     app2
>> >
>> > deps/
>> >     <rebar-managed deps here>
>> >
>> > rel/
>> >     reltool.config
>> >
>> > My rebar.config looks like:
>> > {lib_dirs, ["apps"]}.
>> >
>> > {sub_dirs, [
>> >         "apps/app1",
>> >         "apps/app2",
>> >         "rel"]}.
>> >
>> > {deps, [...]}.
>> >
>> > My reltool.config looks like (cut-n-pasted pieces here):
>> >
>> > {sys, [
>> >        {lib_dirs, ["../apps", "../deps"]},
>> >        {rel, "start", "1",
>> >         [
>> >          app1,
>> >          app2,
>> >          dependent_app1,
>> >          dependent_app1
>> >         ]},
>> >        {rel, "start_clean", "",
>> >         [
>> >          kernel,
>> >          stdlib
>> >         ]},
>> >        {app, app1, [{incl_cond, include}]},
>> >        {app, app1, [{incl_cond, include}]},
>> >        {app, dependent_app1, [{incl_cond, include}]},
>> >        {app, dependent_app2, [{incl_cond, include}]}
>> > }.
>> >
>> >
>> > With this setup, rebar & reltool take the apps under apps/ and deps/ and
>> > creates a target release for me.
>> >
>> > Is this what you are looking for?
>> >
>> > -Garret
>> >
>> > On Tue, Dec 20, 2011 at 11:12 AM, Dmitry Demeshchuk
>> > <demeshchuk@REDACTED>
>> > wrote:
>> >>
>> >> Hello, Siri and everyone.
>> >>
>> >> Recently I've been trying to start using OTP releases in our projects
>> >> with help of rebar. However, I faced the following problem.
>> >>
>> >> Rebar expects that *all* Erlang code resides in some directory
>> >> (generally, "deps" folder) or several directories. This is a reltool
>> >> strict requirement, as far as I understand. Unlike, Riak, all our
>> >> applications have the following directory structure:
>> >>
>> >> .
>> >> ..
>> >> deps/
>> >> ebin/
>> >> include/
>> >> priv/
>> >> src/
>> >>
>> >> So, we pull some libraries (and sometimes smaller applications) as
>> >> deps, but the main application's code resides in the root application
>> >> folder. And there's no way to make reltool include this code into the
>> >> generated release, or at least I don't see it.
>> >>
>> >> For now, there are 2 ways for me to solve this without affecting
>> >> reltool
>> >> itself:
>> >>
>> >> 1. For all apps, make another repository that just pulls our
>> >> application and all its deps, so the actual application code resides
>> >> in the deps/ dir as well, and generate the release package from it.
>> >> However, this seems like an overhead to me. Moreover, this isn't
>> >> convenient for development.
>> >>
>> >> 2. I made a hack that creates symlinks in the deps/ dir, so that it
>> >> seems to reltool that the core application actually resides in the
>> >> deps/ folder, so it's included into the release. Obviously, this is
>> >> kinda ugly and potentially buggy, forget total Windows
>> >> incompatibility. Initially, this was a pull request to rebar but after
>> >> some thinking me and one of rebar's maintainers agreed that it's
>> >> better to make this code a rebar plugin.
>> >>
>> >> So, as you can see, both of the solutions aren't perfect. The ideal
>> >> way I can see is an ability to set explicit app directories in
>> >> reltool.config, like:
>> >>
>> >> {explicit_app_dirs, ["/apps/myapp1"]}.
>> >>
>> >> Probably, it won't make any other use besides the problem I'm
>> >> describing here, but at least it's quite general and doesn't seem like
>> >> a hack. Maybe there's a better way that I didn't come up with. Or
>> >> maybe reltool can do what I want, and I just don't know about such an
>> >> ability.
>> >>
>> >> This seems like a very useful feature. I know that many people use
>> >> just the same directory structure in their projects. Also, rebar
>> >> maintainers already gave me their +1 to this. I'll be glad to work on
>> >> the patch if we come up with a good solution.
>> >>
>> >> Thank you.
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Dmitry Demeshchuk
>> >> _______________________________________________
>> >> erlang-questions mailing list
>> >> erlang-questions@REDACTED
>> >> http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Dmitry Demeshchuk
>
>



-- 
Best regards,
Dmitry Demeshchuk



More information about the erlang-questions mailing list