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.