Changes in config.exs are not reflected in app.conf about exrm

[bitwalker]

I'll take a look tonight, thanks for reporting!

[bitwalker]

Hey @uriagassi, so a couple of things:

1.) The .conf is no longer automatically generated if one doesn't exist. It's now 100% opt-in. However,
2.) If you have a schema.exs, but no .conf, then the default values from the schema will be used over those in config.exs. If you aren't using the schema or the .conf, you can delete both, and config.exs will be used instead.
3.) In general, the .conf is meant to be your release config. Any settings present in the .conf will be used over any other configuration that is available. The order of priority is .conf -> schema.exs default values -> config.exs. If you don't want to use anything other than config.exs, just delete the .conf and schema.exs. Be aware that you'll need to update to exrm 0.12.11 to get those changes though.

[uriagassi]

Thanks! I will give it a try

On 27 July 2014 23:13, Paul Schoenfelder [email protected] wrote:

Hey @uriagassi https://github.com/uriagassi, so a couple of things:

1.) The .conf is no longer automatically generated if one doesn't exist.
It's now 100% opt-in. However,
2.) If you have a schema.exs, but no .conf, then the default values from
the schema will be used over those in config.exs. If you aren't using the
schema or the .conf, you can delete both, and config.exs will be used
instead.
3.) In general, the .conf is meant to be your release config. Any settings
present in the .conf will be used over any other configuration that is
available. The order of priority is .conf -> schema.exs default values ->
config.exs. If you don't want to use anything other than config.exs, just
delete the .conf and schema.exs. Be aware that you'll need to update to
exrm 0.12.11 to get those changes though.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[bitwalker]

@uriagassi any luck?

[uriagassi]

I'm getting the following error when calling mix release:

Unable to copy from .../rel/sys.config to ..../rel/test/releases/0.0.1/sys.config because of {copy_failed, enoent} 
Unable to copy from .../rel/boot to ..../rel/test/bin/test because of {copy_failed, enoent} 

It seems that the files exist under .../rel/files, and not under .../rel...

[bitwalker]

I pushed a new release today, 0.12.12, which fixed an issue with symlinked directories. Are you running the latest? If so, could you give me what OS, Erlang version, and Elixir version you are running?

[uriagassi]

OS: Ubuntu 13.04
Erlang/OTP: 17
Elixir: 0.14.3
exrm: 0.12.12

[uriagassi]

@bitwalker did you check it?

[bitwalker]

@uriagassi I'm working on exrm (plus a few other things) tonight, I'll take a look and report back here before I'm done for the night. Sorry for the delay!

[bitwalker]

@uriagassi Do you have a test project I can try to replicate with? I'm having trouble reproducing this. If you can either give me a test project, or replicate with exrm-test, then I can dig in.

[uriagassi]

I wouldn't know how to replicate the problem - it simply happens at my
project, I don't even know where to start looking for why it happens... Do
you have any hint on why it would look for the files in the wrong place?
maybe some cache I need to delete?

On 3 August 2014 09:07, Paul Schoenfelder [email protected] wrote:

@uriagassi https://github.com/uriagassi Do you have a test project I
can try to replicate with? I'm having trouble reproducing this. If you can
either give me a test project, or replicate with exrm-test
https://github.com/bitwalker/exrm-test, then I can dig in.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[bitwalker]

Could you clone the exrm-test project locally and see if you get the same problem there? Another approach would be to do mix deps.clean exrm conform, mix deps.get exrm conform, and mix deps.compile, and see if that fixes the problem. If that doesn't work, and you don't have any upgrade releases you care about, run mix release.clean --implode and mix release, and see if a fresh release gives you the same trouble. Make sure before you do that, that you pull out any custom configuration you've created under rel, or it will be deleted.

It seems to be an issue with symlinking, but I'm not sure why it's coming up in your particular case. Hopefully you can reproduce with the exrm-test project, but if not, I imagine the only way I'll be able to pin things down is knowing more about the project you are experiencing this with.

How people have typically approached reproducing problems they aren't sure of the source for, is by building on exrm-test and slowly adding configuration that they have in their own project, new dependencies, etc. Once they see the problem there, they push their forked exrm-test repo to GitHub, and I can pull it and test with something known (to me), but with the changes that cause the problem.

[uriagassi]

I will try tomorrow—
Sent from Mailbox

On Sun, Aug 3, 2014 at 6:58 PM, Paul Schoenfelder
[email protected] wrote:

Could you clone the exrm-test project locally and see if you get the same problem there? Another approach would be to do mix deps.clean exrm conform, mix deps.get exrm conform, and mix deps.compile, and see if that fixes the problem. If that doesn't work, and you don't have any upgrade releases you care about, run mix release.clean --implode and mix release, and see if a fresh release gives you the same trouble. Make sure before you do that, that you pull out any custom configuration you've created under rel, or it will be deleted.
It seems to be an issue with symlinking, but I'm not sure why it's coming up in your particular case. Hopefully you can reproduce with the exrm-test project, but if not, I imagine the only way I'll be able to pin things down is knowing more about the project you are experiencing this with.

How people have typically approached reproducing problems they aren't sure of the source for, is by building on exrm-test and slowly adding configuration that they have in their own project, new dependencies, etc. Once they see the problem there, they push their forked exrm-test repo to GitHub, and I can pull it and test with something known (to me), but with the changes that cause the problem.

Reply to this email directly or view it on GitHub:
#49 (comment)

[uriagassi]

After many trials I've managed to reproduce the problem by changing the exrm version on exrm-test to "~> 0.11.2" (I know this defeats the purpose of the test, since its before the fix, but it might give you hints on what happened to me).

Using your suggestion, the error message changed to:

Error in process <0.33.0> with exit value: {function_clause,[{rlx_dscv_util,discover_dir,[#Fun<rlx_app_discovery.4.27708845>,<<53 bytes>>,undefined],[{file,"src/rlx_dscv_util.erl"},{line,81}]},{lists,map,2,[{file,"lists.erl"},{line,1237}]},{ec_plists,'-local_runmany/3-fun-0-',3,[{file,"src/ec_plists.erl"},{line,753}]}]}

escript: exception exit: {function_clause,
                [{rlx_dscv_util,discover_dir,
                     [#Fun<rlx_app_discovery.4.27708845>,
                      <<"/home/ubuntu/projects/bridge/rel/files/../_build/prod">>,
                      undefined],
                     [{file,"src/rlx_dscv_util.erl"},{line,81}]},
                 {lists,map,2,[{file,"lists.erl"},{line,1237}]},
                 {ec_plists,'-local_runmany/3-fun-0-',3,
                     [{file,"src/ec_plists.erl"},{line,753}]}]}
    in function  ec_plists:handle_error/3 (src/ec_plists.erl, line 900)
    in call from ec_plists:local_runmany/3 (src/ec_plists.erl, line 764)
    in call from rlx_dscv_util:do/2 (src/rlx_dscv_util.erl, line 52)
    in call from rlx_app_discovery:resolve_app_metadata/2 (src/rlx_app_discovery.erl, line 103)
    in call from rlx_prv_discover:do/1 (src/rlx_prv_discover.erl, line 46)
    in call from relx:run_provider/2 (src/relx.erl, line 280)
    in call from lists:foldl/3 (lists.erl, line 1261)
    in call from relx:run_providers/1 (src/relx.erl, line 268)

Which I managed to work around after deleting the {app}.conf and {app}.schema.exs files which were created by the older version of exrm.

I hope it helps!

[bitwalker]

Very strange. I think this is related to another bug which I fixed right before you reported this one, but I wouldn't have thought deleting those two files would've done anything. I'll be working on the exrm internals for the next release, so maybe when I get in there I'll see what the problem was. Part of the motivation for deprecating the relx dependency and writing it in Elixir is so that we have a clear troubleshooting path for issues like this one. Thanks again for diving in and tracking the problem down. Sorry I wasn't much help this time around :(.