Overriding recursive dependencies for a single dep

Tim Watson watson.timothy at gmail.com
Mon Jul 25 19:34:54 EDT 2011


Hi Guys,

Thanks for the feedback. I'm going to take this discussion off-list
for now, so I'll ping you both to discuss some of these ideas.

One thing to note which does belong on the list (for others'
reference): if you have eunit specific options you wish to use only
for testing then you can set those in the 'eunit_compile_opts' rebar
config option. These are merged with erl_ops also. That's a good way
to separate build and test options.

Cheers,

Tim

On 25 July 2011 20:52, Brian Rowe <public_browe at muxspace.com> wrote:
> Tim,
>
> This direction looks promising w.r.t. sub_dirs and deps control.
> Regarding the erl_opts control, here are the common scenarios that
> I've been struggling with. Basically if I write a library, I may have
> options set, such as {d,debug} or debug_info. I don't want these set
> when I include the library in a project, but they are useful when I am
> running eunit, etc. Similarly, I've found it useful to pass {d,'TEST'}
> to dependencies during compilation. I think most of this could be
> solved by adding a new root_opts (or similar) for any erl options that
> should only be used when a project is at the top level. Existing
> erl_opts would behave the same as now. If a project is the root of the
> dependency tree, then apply these options to every dependency,
> overwriting any defined in erl_opts. This approach avoids silent
> changes of behavior, by making overrides explicit. One note is that
> there would be no mechanism to disable or delete options set in
> erl_opts via root_opts. For the examples above, it isn't so important
> since none of these options would likely be shipped in a release, so
> they could all live in root_opts. Do let me know if you think this is
> out of scope of the discussion.
>
> One other comment: I'm not a huge fan of 'overrides' as I find it easy
> to confuse subject and object. I wonder if naming it consistent with
> exclude_deps would make it easier to distinguish between them, say
> override_opts.
>
> Warm Regards,
> Brian
>
>
>
> On Fri, Jul 22, 2011 at 5:51 PM, Tim Watson <watson.timothy at gmail.com> wrote:
>> 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
>>
>> _______________________________________________
>> rebar mailing list
>> rebar at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
>>
>



More information about the rebar mailing list