Dependency post_hooks clean override not executed. #2862
Comments
|
I've started looking into this, though I have not yet found how this is or is not being triggered. |
ferd
added a commit
to ferd/rebar3
that referenced
this issue
Feb 19, 2024
The issue appears to be that because the 'clean' operation might be run while dependencies have not yet been compiled, we applied a partial app detection mechanism with `rebar_app_disover:find_apps(..., ..., all, ...)`, which worked to parse "invalid" (unbuilt) apps, but also did not apply overrides. Instead, we trust the `install_deps` provider dependency by reusing the apps as they were fully parsed _if_ they were valid, and falling back to the `rebar_app_discover:find_apps/4` call only to cover the unreadable ones. This, it turns out, has the side effect of properly applying hooks when apps are fully parsed, and fixes erlang#2862
ferd
added a commit
to ferd/rebar3
that referenced
this issue
Feb 19, 2024
The issue appears to be that because the 'clean' operation might be run while dependencies have not yet been compiled, we applied a partial app detection mechanism with `rebar_app_disover:find_apps(..., ..., all, ...)`, which worked to parse "invalid" (unbuilt) apps, but also did not apply overrides. Instead, we trust the `install_deps` provider dependency by reusing the apps as they were fully parsed _if_ they were valid, and falling back to the `rebar_app_discover:find_apps/4` call only to cover the unreadable ones. This, it turns out, has the side effect of properly applying hooks when apps are fully parsed, and fixes erlang#2862
|
See if #2863 works, if it does for you, I'll merge the fix. |
|
Yup! That fixes it. Thanks so much!! |
ferd
added a commit
to ferd/rebar3
that referenced
this issue
Feb 20, 2024
The issue appears to be that because the 'clean' operation might be run while dependencies have not yet been compiled, we applied a partial app detection mechanism with `rebar_app_disover:find_apps(..., ..., all, ...)`, which worked to parse "invalid" (unbuilt) apps, but also did not apply overrides. Instead, we trust the `install_deps` provider dependency by reusing the apps as they were fully parsed _if_ they were valid, and falling back to the `rebar_app_discover:find_apps/4` call only to cover the unreadable ones. This, it turns out, has the side effect of properly applying hooks when apps are fully parsed, and fixes erlang#2862 Note that we can only clean paths safely if the discovery steps for the apps is done with the right profile and options, which may also impact configurations and hooks. So rather than duplicating that, we invoke the 'as' provider. This also opens the door on choosing a different provider (such as 'app_discover' only) down the road if the -a option isn't given.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pre-Check
I could potentially help fix if somebody points me in the right direction.
Environment
Current behaviour
I created two repositories to demonstrate the issue.
https://github.com/cannadayr/rebar_bug_demo and https://github.com/cannadayr/rebar_bug_demo_dep
If you clone
rebar_bug_demo, and compile it, the dependency override will create thefoofile, however thecleanoverride is not executed, and the artifact remains. For example:Expected behaviour
I would expect the
rebar3 clean -ato run thecleanoverride, and potentially remove the artifact on clean. If for some reason the configuration is invalid, then I would expect an error to be thrown when invokingrebar3.The text was updated successfully, but these errors were encountered: