You can't use a provider hook? The other hooks are from rebar2 and shell out so can't update state anyway?

I do use a provider hook, but the result of its do/1 call is not passed through because the run_all_hooks/6 function doesn't return it. Thus, as far as I can tell, I can't modify the State to inject the exclude_modules configuration from within the provider hook.

oh, hm, maybe this is a bug. I'm not sure what the intention was.

This is definitely a good use case so I'd like to support it, we just need to consider the ramifications of modifying this :(

Digging into the history of it, #695 seems to be the main issue. #780 allowed to carry state in hooks if we wanted to.

Despite having that state already set, we never set any hook anywhere by default. The only place we started doing so was in some specific case-by-case basis, such as escripts.

One thing to be careful about though is that because generally hooks are not carrying state, there have been changes done in the past that specifically drop the input command from hooks (see source). As such, there's a chance that starting to carrying state in commands that tend to take arguments (such as releases or tarballs, but was put in to fix issues with test commands) could cause breakage in edge cases.

If we start passing state, we're probably going to need to store the command that was unset and start tracking it again, and risk breakage in setups where not passing state was load bearing somehow because the hook played with state a lot.

I'm noticing that there's also a distinction between hooks that run for each app in an umbrella, and hooks that are applied project-wide. Only the former currently have the ability to track their state. I don't necessarily have a good understanding of what would happen with project-wide hooks tracking and modifying state.

Yeah, and the per-app one is the one that is relevant here (and the far more complicated one :)).

I have already done some wprk in this direction, will push it this week to the draft PR.