Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overlay_vars in a profile is not used #1247

Closed
benoitc opened this issue Jun 25, 2016 · 4 comments · Fixed by #1610
Closed

overlay_vars in a profile is not used #1247

benoitc opened this issue Jun 25, 2016 · 4 comments · Fixed by #1610
Labels
dependency issue resides in a rebar3 dependency

Comments

@benoitc
Copy link
Contributor

benoitc commented Jun 25, 2016

I have a default overl_vars file setup and want to use a different one for prod. But the default on e is always used. Could we replace the hex overlay_vars in profile?

have the following config (edited):

{relx, [
  {release, {'someapp', "0.1.0"}, [someapp]},

  {dev_mode, true},
  {include_erts, false},
  {extended_start_script, true},

  {overlay_vars, "config/vars.config"},
  {overlay, [

...
  ]}
]}.

...
{profiles, [

  {prod, [
    {erl_opts, [
      debug_info,
      {parse_transform, lager_transform},
      {parse_transform, mochicow},
      {d, 'HUT_LAGER'}
    ]},

    {deps, [{lager, "3.0.2"}]},

    {release, [lager, someapp]},

    {relx, [
      {dev_mode, false},
      {include_erts, true},
      {extended_start_script, true},
      {overlay_vars, "config/prod.config"}
    ]}

  ]},

}.

and run rebar3 as prod release.

@benoitc
Copy link
Contributor Author

benoitc commented Jun 25, 2016

So as I read the code the merge in relx for a profile is done here:
https://github.com/erlang/rebar3/blob/master/src/rebar_state.erl#L279

and then you merge the relx config:
https://github.com/erlang/rebar3/blob/master/src/rebar_opts.erl#L118-L119

                  (relx, NewValue, OldValue) ->
                       rebar_utils:tup_umerge(OldValue, NewValue);

When I read the code in rebar_utils I see that the first arg is NewList:

tup_umerge(NewList, OldList) ->
    tup_umerge_(tup_sort(NewList), tup_sort(OldList)).

https://github.com/erlang/rebar3/blob/master/src/rebar_utils.erl#L285-L286

So the code in rebar_opts shouldn't be rebar_utils:tup_umerge(NewValue , OldValue); ?

@dilongl
Copy link

dilongl commented Jul 1, 2016

+1

@ferd ferd added the dependency issue resides in a rebar3 dependency label Jul 11, 2016
@ctrldrift
Copy link

+1

@ferd
Copy link
Collaborator

ferd commented Aug 13, 2017

This may have been fixed in #1606

ferd added a commit to ferd/rebar3 that referenced this issue Aug 15, 2017
This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see erlang#1609)

This is done while adequately maintaining the order of operations that
were required as part of erlang#1563

Overlay vars of profiles are also checked to be taking the same profile
order, along with a test.

This fixes erlang#1247 and erlang#1609
ferd added a commit to ferd/rebar3 that referenced this issue Aug 15, 2017
Specifically, this impacts profiles. It appears that relx as a whole
requires its configuration to be merged in one tuple order (New takes
precedence over Old), whereas the overlays require the opposite (Old
takes precedence over New) since the operation order on disk is
important to work well.

This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see erlang#1609)

This is done while adequately maintaining the order of operations that
were required as part of erlang#1563

Overlay vars of profiles are also checked to be working fine, along with
a test.

This fixes erlang#1247 and erlang#1609
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependency issue resides in a rebar3 dependency
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants