search

erlef / rebar3_hex

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

Use first repository organization over default #112

Closed starbelly closed 5 years ago

starbelly commented 5 years ago

In the case where the user has a repo in their config: 

{erl_opts, [debug_info]}.
{deps, [rebar3_hex]}.
{hex, [{repos, [#{name => <<"hexpm:jellybeam">>}]}]}.

And the user doesn't supply the repo the want to publish to on the command line, accidents can happen (i.e., you publish your private package to the public hexpm repo). In order to mitigate this we should follow suite with mix/hex and default to using the repo defined in config vs the default repo... if no repo is found in config, then prefer the default.

Now, iirc the intention was to allow a project to have multiple repositories defined in config. That part I still don't grok as you can not publish a private package to an org with dependencies from other orgs per the hex docs. If we still want that flexibility, then we'll want to provide an additional configuration option such as organization. I still don't grok the multi-repo bit, but yeah. It may be that I am not recalling correctly and that we only put repos in a list for the sake of merging with the default repo.

Regardless, if the user wants to be able to avoid accidents, they should be able to do so. The -r switch would still be honored of course and take precedence over what's in the config file.

tsloughter commented 5 years ago

Maybe we just shouldn't allow publishing without passing an explicit repo if there are multiple repos defined.

starbelly commented 5 years ago

@tsloughter Either way is fine. I think we currently do what we do do be in line with hex UX, but I am ok with either. Whatever is going to provide more "safety".

tsloughter commented 5 years ago

Yea, I think safest would be to require -r unless there are no custom repos defined.

starbelly commented 5 years ago

K, I'll open a new PR to do that sometime tomorrow.