[erlang-questions] Rebar dependency recursion

[Tuncer Ayaz]

On Thu, Nov 1, 2012 at 10:02 PM, Jared Morrow <jared@REDACTED> wrote:
> I'd argue that get-deps & compile are the most common functions, and if this
> proposal is to make things more consistent, making those commands (and
> others that should almost always have recursion) magically recurse without
> the '-r' passed in would be bad.  So all the "-r +1's" people are saying
> should count towards people who really want to write, "rebar -r compile"
> everytime they compile.  Also, you still won't be able to mix recursive and
> non recursive commands in one call.

The idea is that you only want to recursively compile on get-deps,
update-deps, or if you have sub_dirs and want to compile all
apps.

> On Thu, Nov 1, 2012 at 1:10 PM, Fredrik Linder <fredrikelinder@REDACTED>
> wrote:
>>
>> -r: +1
>>
>> /Fredrik
>>
>> On 1 nov 2012, at 12:00, Tim Watson <watson.timothy@REDACTED> wrote:
>>
>> > This is all fine, but it's mighty annoying to have run rebar repeatedly
>> > because you want to get-deps first then do something else.
>> >
>> > Modules already have a way to indicate that they want recursion -
>> > preprocess/2.  Can this be extended so that modules can say 'I want
>> > recursion' or [predirs] or ok/nothing? Then you'd get a nice interplay where
>> > rebar_deps says [predirs] and rebar_compile says 'yes please' to the
>> > recursion into those predirs but rebar_templater says 'no thanks' to them
>> > and you can chain commands cleanly without invoking rebar multiple times.
>> >
>> > In that scheme, -r means 'override the guys who said no to recrusion'
>> >
>> > Sent from my iPhone.
>> >
>> > On 1 Nov 2012, at 17:07, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
>> >
>> >> 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.
>> >> _______________________________________________
>> >> erlang-questions mailing list
>> >> erlang-questions@REDACTED
>> >> http://erlang.org/mailman/listinfo/erlang-questions
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>