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