Using current version on github I have the following error about rebar3_appup_plugin HOT 20 CLOSED

interesting, can you share your use case?

from rebar3_appup_plugin.

I've had this crashdump after deleting _build, and calling rebar3 release (which calls rebar3 appup compile). The project had quite some dependencies, but probably appup compile will fail even with a single dependency. I can create a simple scenario to reproduce the error if it does not want to occur with this very simple case.

from rebar3_appup_plugin.

That simple scenario would be much appreciated, it makes it a lot easier to track down the issue,
i use this repo (https://github.com/lrascao/relapp1) to build the test cases for the plugin, maybe you can take out a branch from that to build your error case

from rebar3_appup_plugin.

I was trying to reproduce the same error with relapp1, and of course it was working with the current develop branch, but I had the same problem when I added one of our internal projects to deps.

So this parsed_deps when using this project is not in Opts of rebar_state. I was looking into rebar3 trying to figure out why it is not set correctly. Do you have an idea why it is not set there ?(if I'm not wrong it should be set in rebar_prv_update).

If it helps I will try to share the rebar.config of that project with you.

from rebar3_appup_plugin.

If it helps I will try to share the rebar.config of that project with you.

please, i'm also at a loss as to the reason of the error

from rebar3_appup_plugin.

ok, i'm also now getting the same error, should be easier to track down the issue now

from rebar3_appup_plugin.

I've found the reason behind my issue, might be yours as well. I have an umbrella project with a rebar.config at the root and another rebar.config at apps/app/rebar.config, my provider_hooks directive was located at the latter location, after moving it to the root of the project things started working as expected. I think the reason behind this is related with rebar3's plugin provider dependency handling.

from rebar3_appup_plugin.

The hooks behave differently when there's umbrella apps. From http://www.rebar3.org/docs/configuration#section-hooks regarding compile and clean:

These hooks are, by default, running for every application, because dependencies may specify their own hook in their own context. The distinction is that in some cases (umbrella apps), hooks can be defined on many levels (omitting overrides):

• the rebar.config file at the application root
• each top-level app's (in apps/ or libs/) rebar.config
• each dependency's rebar.config

By default, when there is no umbrella app, the hook defined in the top-level rebar.config is attributed to be part of the top-level app. This allows the hook to keep working for a dependency when the library is later published.

If however the hook is defined in rebar.config at the root of a project with umbrella applications, the hooks will be run before/after the task runs for all of the top-level applications.

To preserve the per-app behaviour in an umbrella project, hooks must instead be defined within each application's rebar.config.

from rebar3_appup_plugin.

So apparently when rebar3 is running the hook defined in a top level app it doesn't have the parsed_deps entry in it's state, in my project i set the deps in the application root rebar.config

from rebar3_appup_plugin.

Hi.
I think it was similar for you. I've created a minimal app where appup compile fails with this reason.
There is a ./rebar.config, src/${PROJ}.appup.src and src/${PROJ}.app.src. Nothing else. The dict:fetch line is called only when there is at least one appup.src.

https://github.com/tothlac/appupfail

from rebar3_appup_plugin.

More exactly appup compile does not fail, but if it is called through provider hook, rebar3 compile/release I have the error.

from rebar3_appup_plugin.

thanks for that, it helps a lot.
@ferd this is a weird one, app_discovery is defined as a dependency of the plugin and that's where parsed_deps is set, shouldn't it be defined? Alternatively, is there a better way of extracting a list of rebar_app_info_t dep records from rebar3?

from rebar3_appup_plugin.

rebar_state:project_apps(State) and rebar_state:all_deps(State) should return you all the app info tuples you need. If you want the deps part of it, you need to depend on lock ideally (or any providers that depends on it, like compile)

from rebar3_appup_plugin.

#26 should fix this, @tothlac can you try it out please?

from rebar3_appup_plugin.

@lrascao
The same to me with the version of 2.3.0.
All my applications with .appup.src cannot compile.

from rebar3_appup_plugin.

Hi & Happy New Year.

I've tried out the change, and it works perfectly. Thank you for the fix!

By the way I would like to implement a feature which can be implemented in the appup plugin or separately in a different plugin.

It does not look difficult to implement it, probably it would not be a big change in rebar3_appup_generate.erl.

So, here is the feature we would like to have:

rebar3 appup generate plugin generates appup files using the following format:

> cat relapp.appup
%% appup generated for relapp by rebar3_appup_plugin (2018/01/03 09:06:17)
{ "1.0.16",
    [{ "1.0.15",
        [{load_module,relapp_m1,brutal_purge,brutal_purge,[]}] }],
     [{ "1.0.15",
        [{load_module,relapp_m1,brutal_purge,brutal_purge,[]}] }]
}.

The contents of relapp.appup.pre.src and relapp.appup.post.src files should be merged into the relapp.appup so that the commands from relapp.appup.pre.src should precede the commands defined in the generated appup file, and commands from relapp.appup.post.src should come after those commands.

The two files will have similar format:

> cat src/relapp.appup.pre.src
[
 { "1.0.16",
    [{ "1.0.15",
        [{apply, io, format, ["Upgrading from 1.0.15 to 1.0.16"]}] }],
     [{ "1.0.15",
        [{apply, io, format, ["Downgrading from 1.0.16 to 1.0.15"]}] }]
},
 { "1.0.17",
    [{ "1.0.16",
        [{apply, io, format, ["Upgrading from 1.0.16 to 1.0.17"]}] }],
     [{ "1.0.16",
        [{apply, io, format, ["Downgrading from 1.0.17 to 1.0.16"]}] }]
}
].


> cat src/relapp.appup.post.src
[
 { "1.0.16",
    [{ "1.0.15",
        [{apply, io, format, ["Upgrade completed from 1.0.15 to 1.0.16"]}] }],
     [{ "1.0.15",
        [{apply, io, format, ["Downgrade completed from 1.0.16 to 1.0.15"]}] }]
},
 { "1.0.17",
    [{ "1.0.16",
        [{apply, io, format, ["Upgrade completed from 1.0.16 to 1.0.17"]}] }],
     [{ "1.0.16",
        [{apply, io, format, ["Downgrade completed from 1.0.17 to 1.0.16"]}] }]
}
].

After merging the contents of the .appup && .pre.appup.src && .post.appup.src files, the appup file should like this:

%% appup generated for relapp by rebar3_appup_plugin (2018/01/03 09:06:17)
{ "1.0.16",
    [{ "1.0.15",
        [
          %% comes from the .pre.appup.src
          {apply, io, format, ["Upgrading from 1.0.15 to 1.0.16"]},
          %% contents from  the original appup files
          {load_module,relapp_m1,brutal_purge,brutal_purge,[]},
          %% comes from the .post.appup.src
          {apply, io, format, ["Upgrade completed from 1.0.15 to 1.0.16"]}
        ] }],
     [{ "1.0.15",
        [
           %% comes from the .pre.appup.src
           {apply, io, format, ["Downgrading from 1.0.16 to 1.0.15"]},
           %% contents from  the original appup files
           {load_module,relapp_m1,brutal_purge,brutal_purge,[]},
           %% comes from the .post.appup.src
           {apply, io, format, ["Downgrade completed from 1.0.16 to 1.0.15"]}
      ] }]
}.

In the version strings patterns should be allowed and comparing the pattern in the .pre.appup.src / .post.appup.src files against the version defined in the .appup file the commands should be merged only if the patterns are matching.

What do you think would it be easy to implement, and should it go into a different plugin?

Regards,
Laszlo

from rebar3_appup_plugin.

Can you elaborate a bit on the use case for this change?

from rebar3_appup_plugin.

It is a good question since appup generate should create the appup file with all the required contents for the upgrade.

However it can't figure out all needed steps automatically. For example as part of the upgrade we have to call some conversion on a riak bucket or some other tasks which could be called manually before/after calling the upgrade.

If the required steps are the same for all version upgrades those steps can be automatically merged this way into the .appup file from those other two .pre.appup.src/.post.appup.src files.

You are right, this can be done by an escript as well, which calls the upgrade and also calls the other manual steps before/after the upgrade, but it would be probably simpler to give the user this option.

from rebar3_appup_plugin.

You can already run code in your .appup.src file (more details here), could this be enough?
Also, can we close this ticket and open a new one to further debate this topic?

from rebar3_appup_plugin.

Sure, we can close this ticket. I will open the new one.

from rebar3_appup_plugin.