Do you mean two calls to the executable or literally two executables?<div><br></div><div>I would strongly -1 the latter.  </div><div><br></div><div>-J<br><br><div class="gmail_quote">On Thu, Nov 1, 2012 at 3:03 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So we need two executables.<div class="im"><br>
<br>
On 11/01/2012 10:02 PM, Jared Morrow wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I'd argue that get-deps & compile are the most common functions, and if<br>
this proposal is to make things more consistent, making those commands<br>
(and others that should almost always have recursion) magically recurse<br>
without the '-r' passed in would be bad. Â So all the "-r +1's" people<br>
are saying should count towards people who really want to write, "rebar<br>
-r compile" everytime they compile. Â Also, you still won't be able to<br>
mix recursive and non recursive commands in one call.<br>
<br>
-J<br>
<br>
On Thu, Nov 1, 2012 at 1:10 PM, Fredrik Linder <<a href="mailto:fredrikelinder@gmail.com" target="_blank">fredrikelinder@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:fredrikelinder@gmail.com" target="_blank">fredrikelinder@gmail.<u></u>com</a>>> wrote:<br>
<br>
  -r: +1<br>
<br>
  /Fredrik<br>
<br>
  On 1 nov 2012, at 12:00, Tim Watson <<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a><br></div><div class="im">
  <mailto:<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.<u></u>com</a>>> wrote:<br>
<br>
   > This is all fine, but it's mighty annoying to have run rebar<br>
  repeatedly because you want to get-deps first then do something else.<br>
   ><br>
   > Modules already have a way to indicate that they want recursion -<br>
  preprocess/2.  Can this be extended so that modules can say 'I want<br>
  recursion' or [predirs] or ok/nothing? Then you'd get a nice<br>
  interplay where rebar_deps says [predirs] and rebar_compile says<br>
  'yes please' to the recursion into those predirs but rebar_templater<br>
  says 'no thanks' to them and you can chain commands cleanly without<br>
  invoking rebar multiple times.<br>
   ><br>
   > In that scheme, -r means 'override the guys who said no to recrusion'<br>
   ><br>
   > Sent from my iPhone.<br>
   ><br>
   > On 1 Nov 2012, at 17:07, Tuncer Ayaz <<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a><br></div><div><div class="h5">
  <mailto:<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a>><u></u>> wrote:<br>
   ><br>
   >> On Thu, Nov 1, 2012 at 5:47 PM, Eric Merrit wrote:<br>
   >>> Guys,<br>
   >>><br>
   >>> I have been talking with Tuncer and seeing the various bits on<br>
  going<br>
   >>> on about handling dependency recursion in rebar. That is<br>
  `skip_deps`<br>
   >>> vs `-r`. When you mix into that things like config inheritance it<br>
   >>> becomes a mess. I thought I would see if I can get some<br>
  consensus on<br>
   >>> the matter. Just as a short FYI, here are some issues on this<br>
  topic.<br>
   >>><br>
   >>> * <a href="https://github.com/basho/rebar/issues/303" target="_blank">https://github.com/basho/<u></u>rebar/issues/303</a><br>
   >>> * <a href="https://github.com/basho/rebar/issues/275" target="_blank">https://github.com/basho/<u></u>rebar/issues/275</a><br>
   >>> * <a href="https://github.com/basho/rebar/pull/293" target="_blank">https://github.com/basho/<u></u>rebar/pull/293</a> - (this has been merged)<br>
   >>><br>
   >>> I think the default case in rebar is that you *do not want it to<br>
   >>> recurse*. Only in the case of a `get-deps` followed by a `compile`<br>
   >>> do you want to do things recursively. This is almost always true in<br>
   >>> my case, other`s experiences may vary.<br>
   >>><br>
   >>> That being the case I think the default behavior should be the<br>
   >>> non-recursive option and you explicitly tell rebar to recurse with<br>
   >>> the `-r`. As a variation it will probably be worthwhile to<br>
  support a<br>
   >>> list of applications to talk about app specific recursion. In this<br>
   >>> model `-r`/`--recursive` would do recursion as it normally does<br>
   >>> while `--recursive=app1,app2,app3` would only recurse into app1,<br>
   >>> app2 and app3 respectively. There is a branch implementing basic<br>
   >>> -r/--recursive linked in rebar/issues/303 (dss-fix-skip-deps).<br>
   >>><br>
   >>> This seems to be the most simplest solution to the problem and<br>
   >>> doesn't really introduce new semantics though it does inverse<br>
   >>> semantics. The downside to this is that its backwards incompatible.<br>
   >>> However, we are coming up on a new major version so it's a good<br>
   >>> opportunity to do backwards incompatible changes. I don't see a<br>
   >>> solid way for rebar to automatically decide which tasks to<br>
  carry out<br>
   >>> recursively and which not considering you can have many variations<br>
   >>> of commands to run in a single rebar invocation.<br>
   >>><br>
   >>> In any case, it would be nice to settle the issue, with either<br>
   >>> `skip_deps` is the way going forward or we will be moving to the<br>
   >>> `-r`. Obviously, I would like to see the `-r` option, but settling<br>
   >>> the issue on way or the other is best.<br>
   >><br>
   >> All solutions considered so far, I think introducing an explicit<br>
   >> -r/--recursive as found in dizzy's dss-fix-skip-deps branch is a<br>
  good<br>
   >> solution.<br>
   >><br>
   >> If someone can come up with a solid way to make rebar aware of what<br>
   >> commands are going to be run and use that as a way to dynamically<br>
   >> enable/disable recursion, I'd be very interested to read that. I<br>
  hope<br>
   >> there is a better solution which keeps the ease of use for the<br>
  initial<br>
   >> 'get-deps compile' step while not forcing us to use skip_deps and/or<br>
   >> apps=/skip_apps= afterwards. Config inheritance is a related problem<br>
   >> and discussed in the above ticket #275.<br>
   >> ______________________________<u></u>_________________<br>
   >> erlang-questions mailing list<br></div></div>
   >> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="im">
<br>
   >> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
   > ______________________________<u></u>_________________<br>
   > erlang-questions mailing list<br></div>
   > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="im">
<br>
   > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
  ______________________________<u></u>_________________<br>
  erlang-questions mailing list<br></div>
  <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="im">
<br>
  <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
LoÄc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</font></span></blockquote></div><br></div>