[erlang-questions] Rebar dependency recursion

[Tim Watson]

I'd argue that that's a case of consistency over practicality. Now what was it Oscar Wilde was saying... ;)

Sent from my iPhone.

On 1 Nov 2012, at 21:02, 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.   
> 
> -J
> 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121102/5330843e/attachment.htm>