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>