erlef / rebar3_hex

Rebar3 Hex library
Apache License 2.0
101 stars 49 forks source link

Proposal: drop explicit dependency to hex_core #104

Closed ferd closed 5 years ago

ferd commented 5 years ago

Background information

hex_core is now a dependency of both rebar3 and rebar3_hex. However, since rebar3_hex is a plugin, it will run with a higher priority for its dependencies than rebar3 itself might, and this may cause issues when rebar3 tries to build things with the hex_core lib as specified by rebar3_hex. This is a bit of a limitation because rebar3's own internals use the same structure as plugins do.

Proposal

Have rebar3_hex depend on hex_core, but not explicitly, just implicitly. This means that what we'd want to do is identify the hex_core modules rebar3_hex depends on, and making sure they are loaded in rebar3. Then rebar3_hex can remove its dependency on hex_core when publishing to hex.pm and instead implicitly depend on rebar3 versions rather than hex_core versions.

The reason for this is that by working this way, rebar3_hex becomes responsible for handling various layers of backwards compatibility. This means that when we mess up and an incompatibility exists, rather than breaking all rebar3 builds, we only break the functionality related to publishing to hex.pm that this plugins handles.

The compromise here is that rebar3_hex breaking should impact a lot fewer users than a rebar3 breakage itself. In both cases both rebar3 and rebar3_hex need to agree on the version to be used and both repos need to be upgraded together, but the API dependency and versioning is more easily controlled that way.

Caveats

Related:

ferd commented 5 years ago

Heh, turns out the dep part has already been shifted out of rebar3_hex in January, so nevermind, this is mostly done already.

We just need to be more explicit about that kind of support when developing. Close this at will.

tsloughter commented 5 years ago

Should this be closed?

starbelly commented 5 years ago

Makes sense to close it to me.