Closed ElectronicRU closed 3 years ago
@ElectronicRU, could you try and use https://github.com/erlang/rebar3/pull/2542 to see if it solves your issue? Thanks.
The other common source of issues around these things ("needing a second compile and then it works") is that the dep name as declared in {deps, [{DepName, ...}]}
does not match the actual OTP application name.
Huh - but in this case, it's a plugin with empty deps. Could the issue be that the plugin app doesn't depend on rebar, somehow? I'll check.
The plugin app should not depend on rebar. Do check if the plugin itself is misnamed.
Doesn't seem to be, no.
Is there any way to reproduce this? There seems to be reliance on a private plugin, I'm not sure there's much we can do at this point.
Unfortunately, yeah :( I think this can be closed for now, I wasn't able to find a smaller breaking example. Once I negotiate releasing the plugin code to open source land, I'll reopen this.
The issue
When upgrading a custom compiler plugin (it compiles JSON Schema v4 to Erlang), a transient crash (undef) happens. It happens consistently when an upgrade actually happens, but does fine (and re-compiles it fine), when you re-run.
I'll try and compile a minimal test case, if necessary.
Environment
Unfortunately, I'm not able to open-source the project yet, but I'm working on it. The plugin is your run of the mill rebar_compiler behaviour, does nothing weird, and calls any specific code only in the compile callback -- otherwise pretty similar to e.g. rebar_compiler_yrl.
Current behaviour
Running the command after the ref has updated causes a crash.
Expected behaviour
Not crashing, probably -- this is such a weird issue.