Config provider support

[starbelly]

Currently we have on rebar3.org docs around config commands. This has not been implemented yet. The config command should mirror mix hex as far as UX goes and should serve as a base line for implementation (https://hexdocs.pm/hex/Mix.Tasks.Hex.Config.html#content). One big note is that mix hex adds tuples to their global config file and it is applied to all repositories in config, this makes sense because mix hex only supports hexpm AFAIK. However, we can not do that so long as we support parent repos other than hexpm (which we currently do). I believe for this to work effectively a k/v will have to be placed into the parent repo and applied to all it's children. .

There's another decision that has to be made : Do we cram all this into the existing rebar3_hex_config module or do we move those existing functions into say rebar_hex. I started going with the latter, but it might make sense to leave it all be.

The initial implementation should probably not bother with dealing with overrides.

[paulo-ferraz-oliveira]

For reference (this is rebar3.org): http://rebar3.org/docs/package_management/hex_package_management/#config (I assume that's what you're talking about).

Here's a comparison between the two:

rebar3.org	Hex.pm
username	<n/a>
key	<n/a>
api_url	api_url
cdn_url	mirror_url (is it?)
http_proxy	http_proxy
https_proxy	https_proxy
<n/a>	api_key
<n/a>	offline
<n/a>	unsafe_https
<n/a>	unsafe_registry
<n/a>	no_verify_repo_origin
<n/a>	no_proxy
<n/a>	http_concurrency
<n/a>	http_timeout
<n/a>	cacerts_path

Also:

• rebar3 hex config should "List config keys and values"
• rebar3 hex config KEY should "Get or delete config value for KEY" (delete might be config delete KEY, for example)
• rebar3 hex config KEY VALUE should "Set config KEY to VALUE" (which means a key can't be named delete ?)

And then:

• there's environment variables HEX_HOME and MIX_XDG (?).

Lemme know if I can help.

[paulo-ferraz-oliveira]

I believe for this to work effectively a k/v will have to be placed into the parent repo and applied to all it's children. .

I don't understand this.

There's another decision that has to be made : Do we cram all this into the existing rebar3_hex_config module or do we move those existing functions into say rebar_hex. I started going with the latter, but it might make sense to leave it all be.

I'd propose the former: keep stuff in rebar3_hex_config.

[starbelly]

Just to note, there's very little we can support out of the gate from the list above. We're limited to what hex_core support or what we implement, though some keys don't currently make sense in the context of rebar3_hex as rebar3 itself is responsible for actions pertaining to them, such as http_concurrency, cacerts_path, etc.

In the end and for now the list of config keys we can support ends up being being :

    -define(CONFIG_KEYS, [
                           {api_key, #{env => ["HEX_API_KEY"], type => {string, undefined}}},
                           {api_url, #{env => ["HEX_API_URL"], type => {string, undefined}}},
                           {repo_verify, #{env => ["HEX_UNSAFE_REGISTRY"], type => {boolean, false}}},
                           {repo_verify_origin, #{env => ["HEX_NO_VERIFY_REPO_ORIGIN"], type => {boolean, true}}},
                         ]

This doesn't mean we shouldn't push out initial support, just noting.

[starbelly]

I believe for this to work effectively a k/v will have to be placed into the parent repo and applied to all it's children. .

I never answered your question. Mix hex will place the values for the supported keys in global config. We don't have a global config concept in rebar3_hex and I'm not sure we should. Take this case for example, you set api_key, it goes into global config. If you have a repo entry for say hexpm and and a repo entry for my_own_super_private_self_hosted_hexpm how do we know which repos to apply api_key on? We could say, well this is the users responsibility, but eh.

Further, if we support being able to set api_key on hexpm:foo, then we'll never use api_key for hexpm, but in fact api_key should work across any org you have within a global repository, such as hexpm, I believe.

Thus, I think it makes sense for us to support stuffing in key/values in parent repositories. Most of the time, this will only ever be hexpm for most people, so it acts like global config. But in the case you have two different parent repos, you'll need to specify which one the key/value it should be set on.

Edit:

I do think some options make sense globally, such as http_timeout, but these don't really apply to us like they do for mix hex, at least right now.