[erlang-questions] Rebar dependency recursion

[Tuncer Ayaz]

On Thu, Nov 1, 2012 at 5:47 PM, Eric Merrit wrote:
> Guys,
>
> I have been talking with Tuncer and seeing the various bits on going
> on about handling dependency recursion in rebar. That is `skip_deps`
> vs `-r`. When you mix into that things like config inheritance it
> becomes a mess. I thought I would see if I can get some consensus on
> the matter. Just as a short FYI, here are some issues on this topic.
>
> * https://github.com/basho/rebar/issues/303
> * https://github.com/basho/rebar/issues/275
> * https://github.com/basho/rebar/pull/293 - (this has been merged)
>
> I think the default case in rebar is that you *do not want it to
> recurse*. Only in the case of a `get-deps` followed by a `compile`
> do you want to do things recursively. This is almost always true in
> my case, other`s experiences may vary.
>
> 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).
>
> This seems to be the most simplest solution to the problem and
> doesn't really introduce new semantics though it does inverse
> semantics. The downside to this is that its backwards incompatible.
> However, we are coming up on a new major version so it's a good
> opportunity to do backwards incompatible changes. I don't see a
> solid way for rebar to automatically decide which tasks to carry out
> recursively and which not considering you can have many variations
> of commands to run in a single rebar invocation.
>
> In any case, it would be nice to settle the issue, with either
> `skip_deps` is the way going forward or we will be moving to the
> `-r`. Obviously, I would like to see the `-r` option, but settling
> the issue on way or the other is best.

All solutions considered so far, I think introducing an explicit
-r/--recursive as found in dizzy's dss-fix-skip-deps branch is a good
solution.

If someone can come up with a solid way to make rebar aware of what
commands are going to be run and use that as a way to dynamically
enable/disable recursion, I'd be very interested to read that. I hope
there is a better solution which keeps the ease of use for the initial
'get-deps compile' step while not forcing us to use skip_deps and/or
apps=/skip_apps= afterwards. Config inheritance is a related problem
and discussed in the above ticket #275.