Laszlo Toth

The `get_vsn(State) ->` function mentioned above is declared and used by a plugin. When compile is running on the top-level app, it returns the vsn of the top application, but...

So basically the only thing I can do is to construct the version string of the top-level application manually, using a similar code that is executed when rebar3 compiles the...

The problem is that I generate some logging modules. There are dep1_logs.erl, ....., depN_logs.erl, top_level_app_logs.erl files. I generate them from csv files. When dep1_logs:log.... function is called from dep1.erl I...

Having put what you've sent into my rebar.config, I got this error: ``` ===> Unable to parse config. Term is not in {Key, Value} format: #{ => #{api_url => ,...

@aboroska thanks, that's how we fixed the issue. We use an older version of lint, because on one-day errors reported by the plugin started appearing in all of our repositories....

The problem is definitely with the current compile order in rebar3. Now the pre_hooks are called before the dependencies of the project are compiled which is wrong. Fred Herbert mentioned...

So I have just tried it on our projects with a simple modification in katt's code. I've moved prv/katt_blueprint.peg => src/katt_blueprint.peg and added ``` {plugins, [ rebar3_neotoma_plugin ]}. {provider_hooks, [...

Maybe I'm wrong, but as we have ``` {provider_hooks, [ {pre, [{tar, {appup, tar}}]}, {post, [{compile, {appup, compile}}, {clean, {appup, clean}}]} ]}. ``` in our rebar.config release calls first compile,...

One more thing we have found: The atom git most probably comes from the .app.src of the given dependency. There we use ``` {vsn, git}, ``` instead of an exact...

It looks like even though > rebar3 compile generates the .app file with the correct vsn, in appup compile still the vsn coming from the app.src files are used: https://github.com/lrascao/rebar3_appup_plugin/blob/c9fae0f20db3b27b1ef0cc640163eb3690d8e689/src/rebar3_appup_compile.erl#L80...