Rebar dependency recursion - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Rebar dependency recursion
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
Message-ID: <5092E3BE.4090904@ninenines.eu>
Date: Thu, 01 Nov 2012 22:03:58 +0100
From: =?ISO-8859-1?Q?Lo=EFc_Hoguin?= <es...@ninenines.eu>
Organization: Nine Nines
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jared Morrow <ja...@basho.com>
References: <2A5D9D78-C617-45EB-9C94-D42D437FB...@gmail.com>
 <CAOvwQ4gcXXkX2aOS4ufQC+=NhTmKxq+bfDVXrMzWtYEzEP2...@mail.gmail.com>
 <6797EE94-D3DF-4E9F-9808-DF7C5DA6B...@gmail.com>
 <742FB6F9-4E91-44BF-B113-D74CC6746...@gmail.com>
 <CACUSOvdCHmtmbK1N7+V+L2VMxPXc8JwWH3h=RmQbp5pXuLj...@mail.gmail.com>
In-Reply-To: <CACUSOvdCHmtmbK1N7+V+L2VMxPXc8JwWH3h=RmQbp5pXuLj...@mail.gmail.com>
Cc: "erlang-questi...@erlang.org" <erlang-questi...@erlang.org>
Subject: Re: [erlang-questions] Rebar dependency recursion
Precedence: list
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

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 <fredrikelin...@gmail.com
> <mailto:fredrikelin...@gmail.com>> wrote:
>
>     -r: +1
>
>     /Fredrik
>
>     On 1 nov 2012, at 12:00, Tim Watson <watson.timo...@gmail.com
>     <mailto:watson.timo...@gmail.com>> 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 recrusi=
on'
>      >
>      > Sent from my iPhone.
>      >
>      > On 1 Nov 2012, at 17:07, Tuncer Ayaz <tuncer.a...@gmail.com
>     <mailto:tuncer.a...@gmail.com>> 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 merge=
d)
>      >>>
>      >>> 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 `compil=
e`
>      >>> 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 wi=
th
>      >>> the `-r`. As a variation it will probably be worthwhile to
>     support a
>      >>> list of applications to talk about app specific recursion. In th=
is
>      >>> model `-r`/`--recursive` would do recursion as it normally does
>      >>> while `--recursive=3Dapp1,app2,app3` would only recurse into app=
1,
>      >>> 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 incompatib=
le.
>      >>> 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 variatio=
ns
>      >>> 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 settli=
ng
>      >>> 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 wh=
at
>      >> 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=3D/skip_apps=3D afterwards. Config inheritance is a related =
problem
>      >> and discussed in the above ticket #275.
>      >> _______________________________________________
>      >> erlang-questions mailing list
>      >> erlang-questi...@erlang.org <mailto:erlang-questi...@erlang.org>
>      >> http://erlang.org/mailman/listinfo/erlang-questions
>      > _______________________________________________
>      > erlang-questions mailing list
>      > erlang-questi...@erlang.org <mailto:erlang-questi...@erlang.org>
>      > http://erlang.org/mailman/listinfo/erlang-questions
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questi...@erlang.org <mailto:erlang-questi...@erlang.org>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- =

Lo=EFc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
