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