Closed ferd closed 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.
Should this be closed?
Makes sense to close it to me.
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
hex_core
versions, so the gain will only be between this plugin and rebar3 itself. However, users ofhex_core
are limited, and dependencies can already safely use whatever version they want; only plugins are restricted.hex_core
versions will become the responsibility of this plugin rather than rebar3, but the plugin could be free to state its restrictions, such as "v6.4.0 requires at least Rebar3 3.8.0" or "v6.6.0 requires rebar3 3.9.0" -- something that Rebar3 is not as free to do todayRelated: