[erlang-questions] Rebar dependency recursion

[Seth Falcon]

On Nov 1, 2012, at 10:07 AM, Tuncer Ayaz wrote:

> On Thu, Nov 1, 2012 at 5:47 PM, Eric Merrit wrote:
>> That being the case I think the default behavior should be the
>> non-recursive option and you explicitly tell rebar to recurse with
>> the `-r`. As a variation it will probably be worthwhile to support a
>> list of applications to talk about app specific recursion. In this
>> model `-r`/`--recursive` would do recursion as it normally does
>> while `--recursive=app1,app2,app3` would only recurse into app1,
>> app2 and app3 respectively. There is a branch implementing basic
>> -r/--recursive linked in rebar/issues/303 (dss-fix-skip-deps).

I'm +1 on a move to -r over skip_deps.

Has there been discussion on the idea of commands defining recursive behavior themselves?

There are some commands where recursion is never correct (e.g. creating a template or generating a release). And commands where I think lack recursion needs to be the default like get-deps. The challenge is that there are a number of commands where both behaviors are reasonable depending on your use (compile, clean, and eunit in particular).

One idea for keeping some of the ease for initial build would be to provide two versions of some commands so that they can be composed:

   rebar get-deps rcompile eunit
   
    recursive: get-deps rcompile
    non-recursive: eunit

If we don't arrive at a compromise and have to pick either skip_deps or -r, then I strongly favor -r. In either case, you may not get what you wanted. With default being recursive you will sometimes get a completely broken thing (create template) whereas with default non-recursive, some of the right thing will have happened.

+ seth