[erlang-questions] Rebar dependency recursion

Jared Morrow jared@REDACTED
Thu Nov 1 22:06:40 CET 2012 

Do you mean two calls to the executable or literally two executables?

I would strongly -1 the latter.

-J

On Thu, Nov 1, 2012 at 3:03 PM, Loïc Hoguin <essen@REDACTED> wrote:

> So we need two executables.
>
>
> On 11/01/2012 10:02 PM, Jared Morrow 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
>> <mailto:fredrikelinder@REDACTED**com <fredrikelinder@REDACTED>>> wrote:
>>
>>     -r: +1
>>
>>     /Fredrik
>>
>>     On 1 nov 2012, at 12:00, Tim Watson <watson.timothy@REDACTED
>>     <mailto:watson.timothy@REDACTED**com <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
>>     <mailto: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/303>
>>      >>> * https://github.com/basho/**rebar/issues/275<https://github.com/basho/rebar/issues/275>
>>      >>> * https://github.com/basho/**rebar/pull/293<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 <mailto:erlang-questions@**erlang.org<erlang-questions@REDACTED>
>> >
>>
>>      >> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>      > ______________________________**_________________
>>      > erlang-questions mailing list
>>      > erlang-questions@REDACTED <mailto:erlang-questions@**erlang.org<erlang-questions@REDACTED>
>> >
>>
>>      > http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>     ______________________________**_________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED <mailto:erlang-questions@**erlang.org<erlang-questions@REDACTED>
>> >
>>
>>     http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>>
>>
>> ______________________________**_________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>
> --
> Loďc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121101/d79bb881/attachment.htm>

More information about the erlang-questions mailing list