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

[Siri Hansen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111229/144c6ff9/attachment.htm>