Hello there - unfortunately I don't have time to maintain this project anymore. If you're interested in taking over, send me an email and I'm happy to help with the transition.
If you're a user of this library, consider switching to gh or ghapi3, which are both newer and more actively maintained.
These are bindings for the Github web service API as of version 3. For full documentation, please refer to the Github developer API.
> ctx = interactive.login(client.id, client.secret)
> me = get.myself(ctx)
> me$content$public_repos
[1] 17
> star.repository("cscheid", "guitar", ctx)
> unstar.repository("cscheid", "guitar", ctx)
In order to use most of their API, Github requires you to register an application. You'll need to do this if you want to change information, repositories, post gists, etc.
If you will authenticate your Github account interactively (using the
OAuth dance, for example), you should point the Callback URL to
"http://localhost:1410". This is so that interactive.login works:
the interactive OAuth login dancing involves redirection to a URL that
is specified in advance. httr
creates a web server on port 1410 to catch the redirection request and
the token that comes with it.
To log in, you will need the Application Client ID and Secret, and you will call the following function in your R script:
> ctx = interactive.login(client.id, client.secret, scopes=c("gist"))
This will open a web browser where the caller of the R script (presumably, you) will be asked to type their Github username and password. Give more scopes to allow the bindings to do more things (more on oAuth scopes).
If you have obtained an
OAuth access token by some
other method, you can pass it directly to create.github.context. In
fact, interactive.login does little else than securing access to a
token interactively, and then calling create.github.context.
In other words, you should use create.github.context if some other
part of your application is in charge of obtaining the OAuth access
token.
You can also use create.github.context to create anonymous access
contexts. You will be able to make some calls into the API, but not
all of them, and you will be much more severely rate-limited. See the
documentation for details.
DO NOT PUT THE CLIENT SECRET ON A PUBLICLY VISIBLE LOCATION. This is equivalent to an application-wide password. It is used by Github to track API usage, and could be used to impersonate your app. Store it in a safe location (like a locally-encrypted file in your local filesystem), ask the user to type it, or pass it via environment variables from the shell.
All API entry points are very shallow wrappers around Github's API. Once you logged in, all calls to the API take the result of web.login. Examples:
> repos = get.my.repositories(ctx)
> repos = get.my.repositories(ctx, type="owner")
The result of all calls to the API is the request from httr. Most of
the time you will want the response contents, accessible through httr's
content(). This is automatically parsed into JSON, the message
format used throughout's the api:
> me = get.myself(ctx)
> me$content$public_repos
[1] 17
The naming of the function calls is always meant to evoke an order. It starts with a verb and follows with the appropriate objects:
> evts = get.public.events(ctx)
> result = is.repository.starred.by.me("cscheid", "facet")
> star.repository("cscheid", "guitar", ctx)
> unstar.repository("cscheid", "guitar", ctx)
When the Github API specifies "inputs", such as with blob
creation,
you will send the JSON content as the last parameter, named content:
> create.blob(ctx, "cscheid", "guitar", list(content="This is a new blob", encoding="utf-8"))
When the Github API specifies extra parameters, such as when listing repositories, you will pass parameters directly to the API call, like you've already seen above:
# Get all my repositories, sorted by when I last pushed to them
> repos = get.my.repositories(ctx, type="owner", sort="pushed")
- Keep track of rate limits
- Honor event API
X-Poll-Intervalquery rate limits automatically