What to do with NA input to `gh()`?

[jennybc]

If ... in gh(endpoint, ...) contains an NA, gh() errors with this:

 Error in if (endpoint2 != endpoint) { : 
  missing value where TRUE/FALSE needed 

Obviously you'd never do that intentionally. I'm using gh() over rather long lists of (alleged) GitHub users, repos, teams, etc. and sometimes this just happens. I wonder if there's a nicer way to handle?

I'm working on another PR re: errors and will also try to propose something for this.

[gaborcsardi]

Thanks! I am not surprised. As you no, there are no tests. You are my tester. Sorry about it.

So, yes, I am very much looking forward to it.

I'll also try to find some time to set up some test infrastructure, but I don't think that it will happen within 1-2 weeks.

[jennybc]

Your idea re: building a table of endpoints is starting to make more sense to me now! It would be useful for tests (and other purposes too, I think). That Python (?) wrapper I linked to on some other thread basically does that to generate their tests. I would be willing to lend a hand ... but not until my teaching ends (first week of Dec).

[gaborcsardi]

Sounds good to me!

Back then I did some quick searches to find some (even partial) declarative description of the GitHub API, but failed. There are some "API generators", that take such a description, and then generate an API client. (Not in R, obviously.)

As you say, we could use such a description to generate test cases.

Even just creating such a description in a language agnostic way has some value. I'll take another look in a minute.

[jennybc]

http://apievangelist.com/2014/06/05/what-are-the-incentives-for-creating-machine-readable-api-definitions/

although that mostly sounds like something the API creator is supposed to do?

[jennybc]

Or it could be a really tedious web-scraping task. 😕

[gaborcsardi]

That page has some good links. E.g. this looks good:
https://github.com/apiaryio/api-blueprint/

And there a lot of others, e.g. here: https://news.ycombinator.com/item?id=8912897

It is not easy to search for a GitHub api spec, because all these tools are actually on GitHub.

You know what, I'll just ask GitHub support....

[gaborcsardi]

Question sent.

Btw., you said the Python client has this already? Let me take a look.

[gaborcsardi]

Well, they have it in "Python code", so that is not really ideal....

[gaborcsardi]

GH support replied, they don't have a machine-readable api spec, but they want to create one. No ETA, though.

[gaborcsardi]

I mentioned this already for another issue, but there is a good list of endpoints here: https://github.com/mikedeboer/node-github/blob/master/lib/routes.json

[gaborcsardi]

To return back to the original issue, I think NAs should generate errors, no? What else could we do in this case?

[jennybc]

I agree.

I now call gh() almost exclusively in a purrr::safely(gh)() form. To cope with all manner of errors. That probably didn't exist or I didn't know about it when I opened this issue.

In fact, I wonder if if makes sense to build anything like that into gh()?

[gaborcsardi]

I don't think I would run in safely be default. Users can do that if they want, I would just return good errors, i.e. using https://github.com/ropenscilabs/fauxpas or https://github.com/sckott/httpcode.

[jennybc]

No, not by default.

I should clarify that I'm usually using safe_gh() inside purrr::map2() or purrr::pmap(). So I am noticing a very standard set of gymnastic moves that I do before (creating safe_gh()) and after (looking at the errors and, God willing, extracting the "good results").