You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose to rename the package on hex.pm to covertool. Very often the name of the package on hex is the same as the application name. This is actually my first encounter where it's different. Also, the current name suggests it's specifically for rebar which it isn't anymore :-).
With mix you usually write your dependency like this: {:covertool, "~> 1.2"}
The current name requires you to specify the app name as well: {:covertool, "~> 1.2", hex: :rebar_covertool}
With rebar I think it's similar, although I don't know if people are used to that.
On hex we can retire a package with the reason renamed and point people to the new package name. That would help people in moving over.
I'd like to know how others feel about this before submitting a PR.
I'd certainly be open to this. It does seem weird to have the rebar_ prefix when the tool is not rebar-only (and really never was, even before you added mix support: it was also a standalone tool). The current naming is weird for Erlang/rebar3 as well. You include it like this:
That said, I am not sure this would work "out of the box" within the context of a rebar/rebar3 plugin without aliasing the plugin callbacks for rebar2/rebar3 in the covertool module. Right now, they are in the rebar_covertool module, and I don't think the plugin will work if it's not named according to the module of the entry point.
If it's possible to make that work, especially in a backwards-compatible way, I would be all for it.
I ended up doing exactly what you suggested, thanks! It works until projects are going to use the same callback which I don't expect to happen anytime soon.
Besides the PR we still have to retire the old and upload the new package. The old package will stay available for as long as people want to use it.
Activity
nalundgaard commentedon Jun 20, 2018
I'd certainly be open to this. It does seem weird to have the
rebar_prefix when the tool is not rebar-only (and really never was, even before you added mix support: it was also a standalone tool). The current naming is weird for Erlang/rebar3 as well. You include it like this:{plugins, [rebar_covertool]}.or this:
{plugins, [ {rebar_covertool, {git, "https://github.com/covertool/covertool.git", {branch, master}}} ]}.But then, when you're interacting with rebar3, it doesn't appear in the plugins list:
And, when you upgrade the invisible plugin, the output is pretty confusing:
That said, I am not sure this would work "out of the box" within the context of a rebar/rebar3 plugin without aliasing the plugin callbacks for rebar2/rebar3 in the
covertoolmodule. Right now, they are in therebar_covertoolmodule, and I don't think the plugin will work if it's not named according to the module of the entry point.If it's possible to make that work, especially in a backwards-compatible way, I would be all for it.
rename package rebar_covertool to covertool, fixes covertool#42
tverlaan commentedon Jun 21, 2018
I ended up doing exactly what you suggested, thanks! It works until projects are going to use the same callback which I don't expect to happen anytime soon.
Besides the PR we still have to retire the old and upload the new package. The old package will stay available for as long as people want to use it.
rename package rebar_covertool to covertool, fixes covertool#42
Rename plugin to "covertool"
Rename plugin to "covertool"
Rename plugin to "covertool"
Rename covertool package
Rename covertool package
Rename covertool package
Rename covertool plugin to ‘covertool’