                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
Mime-Version: 1.0 (Apple Message framework v1283)
From: Seth Falcon <s...@userprimary.net>
In-Reply-To: <CAOvwQ4gcXXkX2aOS4ufQC+=NhTmKxq+bfDVXrMzWtYEzEP2...@mail.gmail.com>
Date: Thu, 1 Nov 2012 10:37:08 -0700
Message-Id: <A928A2FC-3CBD-4297-B1D6-75F309CC8...@userprimary.net>
References: <2A5D9D78-C617-45EB-9C94-D42D437FB...@gmail.com>
 <CAOvwQ4gcXXkX2aOS4ufQC+=NhTmKxq+bfDVXrMzWtYEzEP2...@mail.gmail.com>
To: Tuncer Ayaz <tuncer.a...@gmail.com>
Cc: erlang-questi...@erlang.org
Subject: Re: [erlang-questions] Rebar dependency recursion
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

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

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions