1. we now rely on $1's vendor.sh script (instead of duplicating it here)
2. we assume that hex_core is rebar3-compatible
3. we rely on TARGET_ERLANG_VERSION
4. we generate exactly what was previously generating, while targeting a specific Erlang/OTP vsn
The shell plugin has to reset the logger by fetching its configuration and
re-applying it later. In the current state, `maybe_reset_logger/1` will only
re-apply part of the configuration (the `config` key), which does not include
other settings such as filters and formatters.
The effect can be demonstrated by adding filters or formatters to `~/.erlang`
and running rebar3 shell on any project (without any --config argument, this
one reload the logger env; updating the kernel/logger environment in
`~/.erlang` fixes it).
For example:
```erlang
logger:set_handler_config(default, #{formatter => {logger_formatter,
#{template => ["> ", msg, "\n"]}}}).
```
This patch makes sure the default handler is re-created with its entire
original configuration.
relx:build_relup does not allow for undefined Release or ToVsn
so we verify that they have been given on the command line
before running relx:build_relup/4.
Based on the closest Alpine Erlang version currently supported by
rebar3. Allows people to mix and match different versions of
the Erlang VM and rebar3 using multi-stage builds.
- add function that allows the complete removal of an entry from auth
config
- add test for rebar_hex_repos:remove_from_auth_config/2
- update test/rebar_pkg_repos_SUITE:auth_read_write_read/1 to use mocks so
we don't append to actual hex.config files
This was a long-standing pending issue with plugins having a weird code
path handling. The work done in the previous commit to do version
detection for the compiler in dependencies along with prior PRs that
added a deps-only mode to the `compile` provider means we can now
re-introduce plugins into the 3.14 compilation mechanism.
This makes compiler version detection a compiler task concern and
removes annoying manual checks, but also solves an unreported issue
(brought up on slack only) where a plugin would no longer have its priv/
or include/ dir included when used as a checkout dependency. Essentially
the latter bug was caused by being out-of-sync with application
preparation for a build task, but by re-folding it into the main flow,
we know we have the proper support as used for deps.
Rather than doing a check on each single file in a dep set (which can
grow quite large), do a dynamic rebuild of deps based on whether the DAG
mentions the files have been modified. To avoid reloading the whole DAG
more than once and then having to still map files, the compiler version
is added to rebar_compiler_erl's CritMeta for the DAG.
This comparison is only set in place to impact the
rebar_prv_install_deps call that handles pruncing and culling deps by
the compiler provider. Intra-DAG comparisons still need to be done by
rebar_compiler_erl for things to work, and the hope is that since most
built-in compiler mods end up generating erl files in deps, that will be
transparent enough to work well.
A DAG call to check the status of the dag (vsn, critmeta, existing,
etc.) has been added to do the faster check there and allowing proper
dispatch.
Plugins couldn't be updated because they don't really use the standard
dep-style facilities for things due to an early filtering.