Proposal: rename package on hex.pm · Issue #42 · covertool/covertool · GitHub
Skip to content

Proposal: rename package on hex.pm #42

Closed

Description

@tverlaan

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.

Activity

  1. nalundgaard commented on Jun 20, 2018

    @nalundgaard
    Member

    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:

    $ rebar3 plugins list
    --- Global plugins ---
    rebar3_hex
    
    --- Local plugins ---
    rebar_raw_resource
    

    And, when you upgrade the invisible plugin, the output is pretty confusing:

    rebar3 plugins upgrade rebar_covertool
    ===> Upgrading covertool ({git,"https://github.com/nalundgaard/covertool.git",
                                          {branch,master}})
    ===> Compiling covertool
    

    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.

  2. added a commit that references this issue on Jun 21, 2018
    e04dbf6
  3. tverlaan commented on Jun 21, 2018

    @tverlaan
    MemberAuthor

    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.

  4. added a commit that references this issue on Jun 21, 2018
    e936e41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions