Overriding recursive dependencies for a single dep

Tim Watson watson.timothy at gmail.com
Fri Jul 22 17:51:23 EDT 2011


On 22 July 2011 20:18, Andrew Thompson <andrew at hijacked.us> wrote:
> On Fri, Jul 22, 2011 at 03:11:40PM -0400, Brian Rowe wrote:
>> Tim,
>>
>> Thanks for the pointers. This is not the first time I've wanted to
>> override values in the rebar.config of a dependency. Another situation
>> I've come across is that if I set erl_opts in a library that is pulled
>> in as a dep, sometimes I want to override that value in my parent
>> project. Unfortunately, the erl_opts of a parent are ignored if
>> erl_opts exist for a dependency (but they are applied if erl_opts was
>> not declared explicitly). Clearly it's not something you always want
>> to do, but there are instances where I've found it to be useful (e.g.
>> defining TEST in all dependencies).
>>
> I ran into this recently as well. Some kind of global erl_opts would be
> really handy.
>
> Andrew
>

Ok this sounds like a patch in the making. Let's just be careful what
we're saying here though - there are two situations when rebar creates
a new (child) config underneath the parent, that we might want to
control:

1. When moving into sub_dirs
2. When moving into directories within deps_dir

So with sub_dirs, I'd really expect the child config to override the
parent config every time. You are in control of the sub_dirs config
yourself, and can therefore decide when to put a general config
setting at the top level (parent) or to override it in the child
(sub_dir).

With deps, I think that you would want to have a very different kind
of control. First of all, the default behaviour for deps must surely
be to let the child (dep) override the parent config that includes it.
Secondly, it would be very useful if you could override the config in
the dep with our own choices. Thirdly, we have to acknowledge that
transitive deps might need to be configured also. This ties in nicely
with another patch I've been discussing recently - optionally
excluding certain transitive deps so you can choose a different
version (for example) - which would give you:

{deps, [
    {riak_kv, "0.14.2", {git, "http://github.com/.....etc"}, [
        {exclude_deps, bitcask},
        %% or {exclude_all_deps, true}

        %% override erl_opts + rebar_plugins with the ones set in
*this* rebar.config
        {overrides, [erl_opts, rebar_plugins]},

        %% override erl_opts inline - not sure if this is
        %% very readable or not - I might drop it
        {overrides, [{erl_opts, [{'d', foobar}]}]}

        %% or alternatively, a custom rebar.config file
        %% this is used especially for this dep!!!
        {alternate_config, "riak_kv.rebar.config"}
    ]},

    %% and if you've excluded a transitive dep, you might
    %% re-include it with your own overrides to its config
    {bitcask, ".*", {git, Url}, [
        %% we will enable PULSE without touching the
        %% rebar.config file that gets pulled from git
        {overrides, [eunit_compile_opts]}
    ]}

    %% naturally we could have done that with {alternate_config, ...}
]}.

{eunit_compile_opts, [
    {d, 'PULSE'},
    {pulse_side_effect, [{bitcask, get_filestate, '_'},
    {bitcask_nifs, keydir_get, '_'}]}
]}.


I haven't put this past the developers yet and will ask for some
clarification before embarking heavily on it. Do let me know if it
looks useful, or if you have any suggestions and/or other ideas.

Cheers,

Tim



More information about the rebar mailing list