Since version 3.3 REBAR_CONFIG defines name for every configuration file

[noproc]

I'm not sure is this intended behaviour or not but since #1387 when REBAR_CONFIG variable is set every erlang project configuration file is assumed to have this name, in other words when set to some value alternative.config rebar tries to load alternative.config for the root project and for dependencies too and the latter is the problem.

Operating System: x86_64-unknown-linux-gnu
ERTS: Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [async-threads:0] [hipe] [kernel-poll:false]
Root Directory: /opt/erlang/erlang-r16/lib/erlang
Library directory: /opt/erlang/erlang-r16/lib/erlang/lib
-----------------
Loaded Applications:
bbmustache: 1.3.0
certifi: 0.4.0
cf: 0.2.2
common_test: 1.7.4
compiler: 4.9.4
crypto: 3.2
cth_readable: 1.2.3
dialyzer: 2.6.1
edoc: 0.7.12.1
erlware_commons: 1.0.0
eunit: 2.2.6
eunit_formatters: 0.3.1
getopt: 0.8.2
inets: 5.9.8
kernel: 2.16.4
providers: 1.6.0
public_key: 0.21
relx: 3.22.2
sasl: 2.3.4
snmp: 4.25
ssl_verify_fun: 1.1.1
stdlib: 1.19.4
syntax_tools: 1.6.13
tools: 2.6.13

-----------------
Escript path: /home/dev/src/rebar/rebar3/rebar3
Providers:
  app_discovery as clean compile compile cover ct deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock new path pkgs release relup report shell state tar tree unlock update upgrade upgrade upgrade version xref 

I expected that the variable controls only the name of the root project's configuration file, not dependencies.
If this is a bug, I can find some time to fix it.

[ferd]

#1387 that was a fix for people using Mix and compiling Elixir it seems. @ericmj I don't know if you all can deal with this together.
I guess we're now on the path of "we need to dig some more" because the temporary fix for Mix and whatnot now breaks other use cases.

[ericmj]

I think Mix can use the same behavior since the bare compiler we use do not load dependencies, it should only load their compiled code (correct me if I'm wrong). The issue I was trying to fix in my PR was that REBAR_CONFIG wasn't consistently being used for the current project, I don't recall that we had any issue with dependencies.

[ferd]

I guess then the fix for this would be to undo the change and only do the ENV-based lookup in the root at rebar3.erl and in the standalone compiler only, but not the rest of lookups. That should be fixable and should work for all use cases.

[ferd]

So there's two other approaches possible:

1. Setting REBAR_CONFIG modifies all the config files read
2. Setting REBAR_CONFIG modifies the reading of the config file at the root of the project only
3. Setting REBAR_CONFIG modifies the reading of the config file at the root of the project and other project apps, but not deps

Currently we do 1, which is broken. A fix for 2 is trivial and I have a version of it already.

A fix for 3 may be confusing since it would impact the root and all of the apps themselves too, unilaterally. Fix is less trivial since it changes the use of app discovery functions based on context.

What do you think should happen between the 3 options here? Also asking the views of @tsloughter, @ericmj, and @talentdeficit

[ferd]

I just checked some providers and deps in _build/lib/ can be matches with that stuff indiscriminately. I think Option 3 is a no-go then. I went with option 2 and opened a PR: #1497

[talentdeficit]

#2 seems sanest and safest to me. assuming it satisfies mix's use this is solved i think?