Incomplete schema mapping from GitHub API to Owner type about github.jl HOT 7 CLOSED

The complete list of missing fields is

    avatar_url
    followers_url
    following_url
    gists_url
    starred_url
    subscriptions_url
    organizations_url
    repos_url
    events_url
    received_events_url
    contributions

Unfortunately, contributions doesn't make sense as an attribute intrinsic to a user account, unless it is explicitly related to the corresponding repo. So maybe this will have to be stored as Dict("JuliaLang/julia" => 716) within the Owner type in the example of the OP.

from github.jl.

Oh never mind, I see that contributions is mapped to the value of the Dict that is output_of_ contributors[1][i].

from github.jl.

Yeah, I left out a good chunk of the *_url fields from various types because most of that info can be naturally obtained/interacted with via the other API methods, but that was probably the wrong decision (also, it left some holes e.g. avatar_url).

Feel free to open a PR with the fix you added.

from github.jl.

avatar_url is just https://avatars.githubusercontent.com/u/$(get(owner.id)). I don't think we should represent these urls in the types, because we also hardcode them in the various accessor methods. I'd rather be consistent about than end up with a weird mix.

from github.jl.

I'd rather be consistent about than end up with a weird mix.

I'm still not opposed to this change (it's better to hew closer to GitHub's actual schema when possible), but this is a good point. We should add the URL fields for every GitHubTypes all at once to avoid confusion or not make the change at all.

cc @KristofferC, since you have a PR for part of this

from github.jl.

What I meant is that we hardcode paths e.g. here: https://github.com/JuliaWeb/GitHub.jl/blob/master/src/owners/owners.jl#L78
with this change, should we change that to

gh_get_paged_json(owner.orgs_url)

If so, that doesn't work with skinny objects any more. If not, then why do we want to expose those fields? We could compute them on-demand from the hardcoded strings.

from github.jl.

Not really since the API is field access?

from github.jl.