Because rebar_core handles skipping apps, we had to specialcase the
handling in the case of update-deps because it has to do its own dep
handling. The way this was done is not particularly clean, but there
currently does not exist another way for a command to signal rebar_core
that it doesn't want rebar_core to pay attention to skip_apps.
With this change, however, you can update-deps even with local
conflicting changes/commits by simply skipping the deps you don't wish
to update, or whitelisting he ones you do wish to update.
This ensures that deps of deps are updated AFTER the dep listing them
is, so that a complicated project with many layers of deps will be
updated correctly. Any new deps encountered along the way are also
cloned, and THEIR deps are also evaluated.
Also added was conflict detection, if a dep has differing versions or
source information, inherited from different places, that will be logged
at the end of update-deps, along with the origin of each conflicting
dep.
- refactor plugin dirs code to be simpler and easier to read
- use erlang-mode's default (%%) comments for portability/consistency
- make sure erlang-mode's indenter is used so that a future whole
buffer indent doesn't get messed up
This patch modifies rebar_core to allow plugins to participate in the
pre and post processing steps, giving plugin authors more flexibility
and control.
This patch fixes the warning logging when the number of missing plugins
is greater than one. The current code only works by accident, when a
single plugin is all that is missing.
This patch updates rebar_core to look for missing plugins (i.e. those
that aren't found on the code path at runtime) in a configurable
plugin directory, and dynamically compile and load them at runtime.
By default, the directory "plugins" is searched, although this can be
overriden by setting the plugin_dir in your rebar.config.
This patch makes a small change in rebar_core that checks the list
of valid plugins to see if any of them export a pre/post processing
function for the current command. This logic is applied only to the
plugins and allows plugin authors to hook into rebar's execution by
using a naming convention that matches the one used for scripting hooks.
Example:
```erlang
-module(my_rebar_plugin).
-export([pre_compile/2]).
pre_compile(Config, AppFile) ->
rebar_log:log(debug, "PRECOMPILE: ~p:~p~n",
[AppFile, Config]),
ok.
```
