Rework repo provider #274
Rework repo provider #274
Conversation
starbelly
commented
Dec 25, 2021
starbelly
commented
- align with organizations from mix hex
starbelly
force-pushed
the
rework-repo
branch
6 times, most recently
from
87df0a5
to
22b52fe
Compare
| handle('GET', [<<"auth">>], Req) -> | ||
| respond_with(200, Req, #{}); | ||
|
|
||
| handle('GET', [<<"orgs">>, <<"foo">>, <<"keys">>], Req) -> |
There was a problem hiding this comment.
This is gross, specifically the hard code, but it'll do for now.
starbelly
force-pushed
the
rework-repo
branch
from
a150260
to
fc3a375
Compare
| %% | ||
| %% Manages the list of authorized hex organizations. | ||
| %% | ||
| %% Note that all commands that require a `NAME' argument expect a qualified repository name for the |
There was a problem hiding this comment.
This is the only thing I'm very unsure of. If we only accept the org part of the repo name, then we have to make some assumptions. In the case you have multiple repos, which one does the org belong to? We can say this is what the -r switch is for, but then we have to say "In this case, you should only specify a parent repository, but in all other cases you can any repository"
If -r only took parent repositories, I'd be ok with just allowing a bare name, but it doesn't, so 🤷 . I mused about switching to that. Basically, it would require that we have a --organization on most tasks.
For example :
rebar3 hex publish -r hexpm --organization foo
or
rebar3 hex organization -r hexpm key foo generate
or
rebar3 hex owner add rebar3_hex [email protected] -r hexpm --organization foo
So, when I think about that just having -r and requiring the fully qualified repo name for the org task sounds quite good to me.
There was a problem hiding this comment.
I feel that ideally you should be able to reuse the same format we use when declaring dependencies, so that the notation is uniform across publishing and usage when possible?
There was a problem hiding this comment.
I agree and what this currently is. That would be hexpm:foo if I'm following correctly. That is, we currently require you to put in {hex, [{repos, [ #{name => <<"hexpm:myorg">>]}]} in rebar.config for fetching private private packages.
In that respect, we should remove support for short hand from publishing. We currently support allowing you to say rebar3 hex publish foo and we will try to find the matching repository, but there's a rub in there, in the case you have an org called foo at two different parent repositories, thus a bug really, no one has run into it yet though.
There was a problem hiding this comment.
Note: We currently have no support in rebar3 (AFAIK) for specifying what repository a dep specifically should come from, this was raised in #262.
There was a problem hiding this comment.
Per this conversation, I will remove support for "shorthand" repo arguments (i.e., -r foo) in the upcoming config provider PR.
| @@ -25,8 +26,7 @@ | |||
|
|
|||
| {dialyzer, [ | |||
| {warnings, [ | |||
| error_handling, | |||
| underspecs | |||
There was a problem hiding this comment.
We'll come back and deal with this later, there's an issue around it.
- repo becomes organization - align interfaces with organizations from mix hex - added rebar3_ex_doc to project_plugins - add initial docs for rebar3_hex_organization - add basic supporting tests
starbelly
force-pushed
the
rework-repo
branch
from
3b06519
to
6af7f54
Compare
