Change api_url to contain /api endpoint

[kubaodias]

When I use mix and rebar3 to connect with hex API they have inconsistent naming of api_url configuration setting. Default rebar3's api_url points to https://hex.pm while mix points to https://hex.pm/api

kuba.odias@mac:~/git/process_group$ mix hex.config api_url http://hex.pdmbuilds.proximetry.com/api
kuba.odias@mac:~/git/process_group$ rebar3 hex config api_url
api_url: http://hex.pdmbuilds.proximetry.com/api

Request with 'rebar3 hex' fails with HTTP 404 Not Found

kuba.odias@mac:~/git/process_group$ DEBUG=1 rebar3 hex key list
===> Load global config file /Users/kuba.odias/.config/rebar3/rebar.config
===> Expanded command sequence to be run: []
===> Expanded command sequence to be run: [{hex,key}]
===> Uncaught error in rebar_core. Run with DEBUG=1 to see stacktrace or consult rebar3.crashdump
===> Uncaught error: {case_clause,{error,404}}
===> Stack trace to the error location:
[{rebar3_hex_key,do,1,
                 [{file,"/Users/kuba.odias/.cache/rebar3/plugins/rebar3_hex/src/rebar3_hex_key.erl"},
                  {line,43}]},
 {rebar_core,do,2,
             [{file,"/home/tristan/Devel/rebar3/_build/default/lib/rebar/src/rebar_core.erl"},
              {line,153}]},
 {rebar_prv_do,do_tasks,2,
               [{file,"/home/tristan/Devel/rebar3/_build/default/lib/rebar/src/rebar_prv_do.erl"},
                {line,68}]},
 {rebar_core,do,2,
             [{file,"/home/tristan/Devel/rebar3/_build/default/lib/rebar/src/rebar_core.erl"},
              {line,153}]},
 {rebar3,main,1,
         [{file,"/home/tristan/Devel/rebar3/_build/default/lib/rebar/src/rebar3.erl"},
          {line,66}]},
 {escript,run,2,[{file,"escript.erl"},{line,759}]},
 {escript,start,1,[{file,"escript.erl"},{line,277}]},
 {init,start_em,1,[]}]
===> When submitting a bug report, please include the output of `rebar3 report "your command"`

Changing api_url to URL without /api works ok

kuba.odias@mac:~/git/process_group$ mix hex.config api_url http://hex.pdmbuilds.proximetry.com
kuba.odias@mac:~/git/process_group$ rebar3 hex config api_url
api_url: http://hex.pdmbuilds.proximetry.com
kuba.odias@mac:~/git/process_group$ DEBUG=1 rebar3 hex key list
===> Load global config file /Users/kuba.odias/.config/rebar3/rebar.config
===> Expanded command sequence to be run: []
===> Expanded command sequence to be run: [{hex,key}]
api_key

However such setting of api_url is not correct for mix.

[ericmj]

The proper fix would be for rebar3_hex to use a different config file than mix since there are no guarantees that either will follow the other's format.

[kubaodias]

I agree however current implementation works only because of the default settings. Another question is: should 'api_url' point to {HEX_PM_URL} or to actual API endpoint {HEX_PM_URL}/api ?

[ericmj]

Since api_url is set when using other endpoints than hex.pm we need to consider that they may have a different URL structure and should not assume not /api.

[kubaodias]

1. What other endpoints than /api are used by rebar3_hex? I couldn't find any in the code.
2. Currently there's an incompatibility in naming of these URLs. Why 'mix hex.config' uses ~/.config/rebar3/rebar.config in the first place?
3. How is it possible to use 'mix' and 'rebar3 hex' in parallel currently when non-standard API URL-s are used?

[ericmj]

1. Only /api is used when using the hex.pm API, but this option is for when not using hex.pm so we should be flexible.

2. It is the other way around, rebar3_hex is using ~/.hex/hex.config.

3. It is not currently. That's what we should fix.

[kubaodias]

Do you have any proposition how it should be fixed to use 'mix' and 'rebar3 hex' concurrently? rebar3_hex plugin uses most of variables from ~/.hex/hex.config (api_url,cdn_url,key,username) so I maybe it's a good idea for rebar3 to use the same config as mix. To sum up: if mix uses api_url with [...]/api suffix and it is sufficient enough I don't know why you want 'rebar3 hex' keep possibility to use other paths.

[ericmj]

Do you have any proposition how it should be fixed to use 'mix' and 'rebar3 hex' concurrently?

Yes, I think rebar3_hex should use a different config file. But it's up to the maintainers of rebar3_hex.

rebar3_hex plugin uses most of variables from ~/.hex/hex.config (api_url,cdn_url,key,username) so I maybe it's a good idea for rebar3 to use the same config as mix.

It's not a good idea that two separate applications with no shared development use the same config. It makes it much harder to make changes to the config when you have worry about breaking another application you have no control over. The fact that we the issue with api url is proof of this. Should mix change or rebar make the change to their config?

To sum up: if mix uses api_url with [...]/api suffix and it is sufficient enough I don't know why you want 'rebar3 hex' keep possibility to use other paths.

I'm not sure what this means? Mix uses no suffix, we directly use the URL that the user has configured with appending anything to it.

[tsloughter]

Yea, we should probably use a different config. The thinking was that sharing one would mean a user would only have to login once to hex and it be good for both tools, as well as being able to define proxies and additional repos in only one place.

As for separate development and hex devs having no control over it, happy to let you have control of the plugin ;)

Or maybe with hex_erl at least that would be in control of hexpm team and we'd just depend on it? So I would take care of just the rebar3 plugin portion.

Only issue may be we have different plans for how multi-repo will work. But I'm not sure that would actually be an issue for this but instead be just differences in how rebar3 handles resolving from repos internally (separate from rebar3_hex) and everything for this plugin would be the same between mix/rebar3_hex.

[wojtekmach]

(...) would mean a user would only have to login once to hex and it be good for both tools (...)

Or maybe with hex_erl at least that would be in control of hexpm

Yes, I think that's a good idea, I can look into that.

Only issue may be we have different plans for how multi-repo will work.

@tsloughter I haven't been following development closely, are the plans written anywhere?

[tsloughter]

Closing this as it is outdated now that we use hex_core.