Can we remove features that rebar3 and hex_core already cover?

[starbelly]

As part of https://github.com/Supersonido/rebar_mix/commit/36617e30e371b0f0490afeacb0f68a3bf4f3425f some features were added that rebar3 and hex_core already cover :

• src/rebar_mix_dep.erl
• src/rebar_mix_hex.erl
• some of what it's in src/rebar_mix_utils.erl

TL;DR is that rebar3 in conjunction with hex_core which ships with rebar3 handles downloading dependencies from hex, locking them, etc.

I feel this plugin would be best just to handle the compilation part, as it was doing prior to this merge.

How do you feel about removing these parts?

[Supersonido]

I have no problem removing it, but you have the option of not to use it. Some people have told me that they use old versions of rebar3 that need those implementations. I'm trying to make it as compatible with all possible versions.

What we can put in the documentation is the preference to use what you propose instead of what is programmed within the library.

What do you think?

[starbelly]

@Supersonido In the end it's of course up to you 😁 . That said, having the option to opt out is definitely desirable. I don't think there is a way to quantify how many people are on versions of rebar3 prior to rebar3 having hex support, maybe you mean people stuck on rebar (pre-rebar3) still?

Maybe another way to look at dropping that support is it might give people incentive to upgrade 😃

One thing I would suggest, if you're going to keep that functionality would be to pull in hex_core for the downloading and unpacking as it does a lot of verification (https://github.com/hexpm/hex_core/). I'm making an assumption you haven't considered that as an option, so forgive me if my assumption is wrong 😇