Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .Rbuildignore
Original file line number Diff line number Diff line change
Expand Up @@ -19,3 +19,4 @@
^\.vscode$
^AGENTS\.md$
^conversation-export\.json$
^vignettes/articles$
2 changes: 0 additions & 2 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,8 +26,6 @@ If you’ve found a bug, please file an issue that illustrates the bug with a mi
The title of your PR should briefly describe the change.
The body of your PR should contain `Fixes #issue-number`.

* For user-facing changes, add a bullet to the top of `NEWS.md` (i.e. just below the first header). Follow the style described in <https://style.tidyverse.org/news.html>.

### Code style

* New code should follow the tidyverse [style guide](https://style.tidyverse.org).
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/pkgdown.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ jobs:
strOwner <- tolower(qcthat::GetGHOwner())
strRepo <- qcthat::GetGHRepo()
strURL <- glue::glue(
"https://{strOwner}.github.io/{strRepo}/pr/{intPRNumber}"
"https://{strOwner}.github.io/{strRepo}/pr/{intPRNumber}/dev"
)
print(paste("🌐 URL:", strURL))
qcthat::CommentIssue(
Expand Down
7 changes: 0 additions & 7 deletions AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,6 @@ beekeeper/
├── AGENTS.md # Main agent setup file
├── DESCRIPTION # Package metadata
├── NAMESPACE # Auto-generated export information
├── NEWS.md # Changelog
└── Various config files # .gitignore, codecov.yml, etc.
Comment thread
jonthegeek marked this conversation as resolved.

---
Expand All @@ -45,12 +44,6 @@ For any feature, fix, or refactor:
6. **Refactor** — clean up, keep tests green.
7. **Document** — document any new or changed exports.
8. **Verify**: Run `devtools::test(reporter = "check")`, then `devtools::check(error_on = "warning")`. Resolve warnings, errors, and NOTEs.
9. **News** — add bullet at top of `NEWS.md` (under dev heading):
- User-facing changes only. 1 line, end with `.`
- Present tense, positive framing, function names (backticks + `()`) near start: `` * `fn()` now accepts ... `` not `* Fixed ...`
- Issue/contributor before final period: `` * `fn()` now accepts ... (@user, #N). `` where `#N` is the GitHub issue number being implemented (e.g. `#42`).
- Get username: `gh api user --jq .login`; get issue number from the user's prompt, the branch name (`git branch --show-current`), or `gh issue list`.
- **Never guess or invent an issue number.** Before writing it, verify: (1) you received it from the user or the branch name, OR (2) you looked it up with `gh`. If you cannot trace the number to a concrete source, use `#noissue`.

---

Expand Down
1 change: 1 addition & 0 deletions DESCRIPTION
Original file line number Diff line number Diff line change
Expand Up @@ -56,3 +56,4 @@ Encoding: UTF-8
Language: en-US
Roxygen: list(markdown = TRUE)
RoxygenNote: 8.0.0
Config/Needs/website: rmarkdown
3 changes: 0 additions & 3 deletions NEWS.md

This file was deleted.

58 changes: 11 additions & 47 deletions README.Rmd
Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,11 @@ knitr::opts_chunk$set(
# beekeeper <a href="https://beekeeper.api2r.org"><img src="man/figures/logo.svg" align="right" height="120" /></a>

<!-- badges: start -->

[![Lifecycle: experimental](https://img.shields.io/badge/lifecycle-experimental-orange.svg)](https://lifecycle.r-lib.org/articles/stages.html#experimental)
[![CRAN status](https://www.r-pkg.org/badges/version/beekeeper)](https://CRAN.R-project.org/package=beekeeper)
[![Codecov test coverage](https://codecov.io/gh/api2r/beekeeper/branch/main/graph/badge.svg)](https://app.codecov.io/gh/api2r/beekeeper?branch=main)
[![R-CMD-check](https://github.com/api2r/beekeeper/actions/workflows/R-CMD-check.yaml/badge.svg)](https://github.com/api2r/beekeeper/actions/workflows/R-CMD-check.yaml)

<!-- badges: end -->

Use beekeeper to create and maintain R packages that wrap APIs.
Expand All @@ -29,57 +30,20 @@ Currently versions 3.0 and 3.1 are supported, with support for swagger 2.0 to co
The APIs must have an API document in yaml format.
The package skeletons generated by beekeeper implement best practices to streamline package development.

## The Plan

This project has been accepted by the [R Consortium 2023 ISC Grant Program](https://www.r-consortium.org/all-projects/awarded-projects/2023-group-1#api2r:%20An%20R%20Package%20for%20Auto-Generating%20R%20API%20Clients)!

This is a rough outline of the planned development milestones of this package, working toward a stable version 1.0.0.
Most of the outline was included in the grant proposal.

- [x] **pre-0.1.0: Infrastructure.**
- I split the OpenAPI-parsing functionality into a separate package, [{rapid}](https://rapid.api2r.org). That package is being developed parallel to this one, and contains all of the *R API D*efinition-specific functionality.
- I also realized I need a package for wrapping {httr2} calls. That package is called [{nectar}](https://nectar.api2r.org), and is also being developed parallel to this one.
- [x] **0.1.0: Basic authentication and endpoint calls.**
- Export a function or functions to generate `R/*.R` files to call an API, given the URL of an OpenAPI spec in YAML format (or a `rapid::class_rapid()` object). The generated files will follow and encourage best practices, and will serve as the core around which the rest of a package would be built.
- Also generate a `tests/testthat/*.R` file for that generated function.
- Generate `R/*.R` and `tests/testthat/*.R` files to authenticate the user (using API keys).
- Produce a vignette about configuring authentication. Folded into the main vignette since it's suprisingly straightforward.
- [x] **0.2.0: OAS definition discovery.**
- Add support for APIs using the OAS json format.
- Streamline discovery of API definitions (with associated error handling).
- **UPDATE:** This functionality is in a separate package, [{anyapi}](https://anyapi.api2r.org).
- [x] **0.3.0: Endpoint function scaffolding.**
- Generate R/*.R and tests/testthat/*.R files for all endpoints ("paths") described in the given API specification.
- The generated functions will work, but error checking, documentation, and tests will be minimal.
- **Potential challenges:** I'll need to strike a balance here between getting a basic working system and producing something that can be easily expanded later.
- **Update:** Also, this likely could go unsaid, but, if the API description is incorrect, the functions will not work as expected. Hopefully their error messages will be helpful for debugging, though!
- [x] **0.4.0: Batching and rate limiting.**
- Add documentation for implementing batching and rate-limiting.
- If possible, export functionality to help implement these processes, but standards seem to vary widely.
- **Potential challenges:** This step will involve more reading and documenting than code, to gather examples of how different APIs implement limits and batching. It's possible systems will be so different that it will be difficult to summarize them. For example, Slack has two separate batching systems in its API, with some functions moved to the newer system, and others not.
- **UPDATE:** The [development version of {httr2}](https://github.com/r-lib/httr2/) has functionality to help with this quite a lot, thankfully! I'm skipping this milestone while that functionality stabilizes (this was previously 0.3.0).
- [ ] **0.5.0: More robust scaffolding.**
- [x] Add parameter documentation.
- [ ] Deal with pagination semi-automatically.
- [ ] **0.6.0: Expected results.**
- [ ] Add response (return value) documentation.
- [ ] Use response (return value) schemas to parse responses.
- [ ] Add parameter type checking.
- [ ] Use expected responses to generate better test scaffolds.
- [ ] **0.7.0: Error messaging.**
- [ ] Add more robust error messaging for non-standard responses.
- [ ] **Potential challenges:** Mocking cases where things fail can be tricky. Ideally this step will involve pushing the package to a stable 1.0.0, but that will require enough usage to feel confident that the core function definitions are stable.
::: .pkgdown-devel
Comment thread
jonthegeek marked this conversation as resolved.

This package is under active development.
See [R Consortium ISC Grant Milestones](https://beekeeper.api2r.org/dev/articles/milestones.html) for details about the development process.

:::

## Installation

::: .pkgdown-release
Comment thread
jonthegeek marked this conversation as resolved.
Install the released version of beekeeper from [CRAN](https://cran.r-project.org/):

```{r, eval = FALSE}
# (not yet, so instead install the dev version)
# install.packages("pak")
pak::pak("api2r/beekeeper")
```
This package is not yet available on CRAN.
See [the dev version](https://beekeeper.api2r.org/dev) for information about the in-progress version of the package.

:::

::: .pkgdown-devel
Expand Down
97 changes: 11 additions & 86 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,10 @@

[![Lifecycle:
experimental](https://img.shields.io/badge/lifecycle-experimental-orange.svg)](https://lifecycle.r-lib.org/articles/stages.html#experimental)
[![CRAN
status](https://www.r-pkg.org/badges/version/beekeeper)](https://CRAN.R-project.org/package=beekeeper)
[![Codecov test
coverage](https://codecov.io/gh/api2r/beekeeper/branch/main/graph/badge.svg)](https://app.codecov.io/gh/api2r/beekeeper?branch=main)
[![R-CMD-check](https://github.com/api2r/beekeeper/actions/workflows/R-CMD-check.yaml/badge.svg)](https://github.com/api2r/beekeeper/actions/workflows/R-CMD-check.yaml)

<!-- badges: end -->

Use beekeeper to create and maintain R packages that wrap APIs. The
Expand All @@ -24,95 +23,21 @@ This package focuses on APIs that follow the [OpenAPI Specification
have an API document in yaml format. The package skeletons generated by
beekeeper implement best practices to streamline package development.

## The Plan

This project has been accepted by the [R Consortium 2023 ISC Grant
Program](https://www.r-consortium.org/all-projects/awarded-projects/2023-group-1#api2r:%20An%20R%20Package%20for%20Auto-Generating%20R%20API%20Clients)!

This is a rough outline of the planned development milestones of this
package, working toward a stable version 1.0.0. Most of the outline was
included in the grant proposal.

- [x] **pre-0.1.0: Infrastructure.**
- I split the OpenAPI-parsing functionality into a separate package,
[{rapid}](https://rapid.api2r.org). That package is being developed
parallel to this one, and contains all of the *R API
D*efinition-specific functionality.
- I also realized I need a package for wrapping {httr2} calls. That
package is called [{nectar}](https://nectar.api2r.org), and is also
being developed parallel to this one.
- [x] **0.1.0: Basic authentication and endpoint calls.**
- Export a function or functions to generate `R/*.R` files to call an
API, given the URL of an OpenAPI spec in YAML format (or a
`rapid::class_rapid()` object). The generated files will follow and
encourage best practices, and will serve as the core around which
the rest of a package would be built.
- Also generate a `tests/testthat/*.R` file for that generated
function.
- Generate `R/*.R` and `tests/testthat/*.R` files to authenticate the
user (using API keys).
- Produce a vignette about configuring authentication. Folded into the
main vignette since it’s suprisingly straightforward.
- [x] **0.2.0: OAS definition discovery.**
- Add support for APIs using the OAS json format.
- Streamline discovery of API definitions (with associated error
handling).
- **UPDATE:** This functionality is in a separate package,
[{anyapi}](https://anyapi.api2r.org).
- [x] **0.3.0: Endpoint function scaffolding.**
- Generate R/*.R and tests/testthat/*.R files for all endpoints
(“paths”) described in the given API specification.
- The generated functions will work, but error checking,
documentation, and tests will be minimal.
- **Potential challenges:** I’ll need to strike a balance here between
getting a basic working system and producing something that can be
easily expanded later.
- **Update:** Also, this likely could go unsaid, but, if the API
description is incorrect, the functions will not work as expected.
Hopefully their error messages will be helpful for debugging,
though!
- [x] **0.4.0: Batching and rate limiting.**
- Add documentation for implementing batching and rate-limiting.
- If possible, export functionality to help implement these processes,
but standards seem to vary widely.
- **Potential challenges:** This step will involve more reading and
documenting than code, to gather examples of how different APIs
implement limits and batching. It’s possible systems will be so
different that it will be difficult to summarize them. For example,
Slack has two separate batching systems in its API, with some
functions moved to the newer system, and others not.
- **UPDATE:** The [development version of
{httr2}](https://github.com/r-lib/httr2/) has functionality to
help with this quite a lot, thankfully! I’m skipping this
milestone while that functionality stabilizes (this was previously
0.3.0).
- [ ] **0.5.0: More robust scaffolding.**
- [x] Add parameter documentation.
- [ ] Deal with pagination semi-automatically.
- [ ] **0.6.0: Expected results.**
- [ ] Add response (return value) documentation.
- [ ] Use response (return value) schemas to parse responses.
- [ ] Add parameter type checking.
- [ ] Use expected responses to generate better test scaffolds.
- [ ] **0.7.0: Error messaging.**
- [ ] Add more robust error messaging for non-standard responses.
- [ ] **Potential challenges:** Mocking cases where things fail can be
tricky. Ideally this step will involve pushing the package to a
stable 1.0.0, but that will require enough usage to feel confident
that the core function definitions are stable.
<div class=".pkgdown-devel">

This package is under active development. See [R Consortium ISC Grant
Milestones](https://beekeeper.api2r.org/dev/articles/milestones.html)
for details about the development process.

</div>

## Installation

<div class=".pkgdown-release">

Install the released version of beekeeper from
[CRAN](https://cran.r-project.org/):

``` r
# (not yet, so instead install the dev version)
# install.packages("pak")
pak::pak("api2r/beekeeper")
```
This package is not yet available on CRAN. See [the dev
version](https://beekeeper.api2r.org/dev) for information about the
in-progress version of the package.

</div>

Expand Down
2 changes: 2 additions & 0 deletions vignettes/articles/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
*.html
*.R
81 changes: 81 additions & 0 deletions vignettes/articles/milestones.Rmd
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
---
title: "R Consortium ISC Grant Milestones"
---

```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>"
)
```

This project is partially funded by the [R Consortium 2023 ISC Grant Program](https://r-consortium.org/all-projects/2023-group-1.html#api2r-an-r-package-for-auto-generating-r-api-clients).
To track the development toward that grant, here I log the milestones from the grant proposal, with notes about progress, challenges, and changes.

- [x] **pre-0.1.0: Infrastructure.**
- I split the OpenAPI-parsing functionality into a separate package, [{rapid}](https://rapid.api2r.org).
That package is being developed parallel to this one, and contains all of the *R API D*efinition-specific functionality.
- I also realized I need a package for wrapping [{httr2}](https://httr2.r-lib.org) calls.
That package is called [{nectar}](https://nectar.api2r.org), and is also being developed parallel to this one.
- [x] **0.1.0: Basic authentication and endpoint calls.**
- Proposal wording:
- Export a function to generate `R/*.R` and `tests/testthat/*.R` files to authenticate the user and make a call to the API, given the URL of an OpenAPI spec in YAML format.
The generated files will follow and encourage best practices, and will serve as the core around which the rest of a package would be built.
- Produce a vignette about configuring authentication.
- Potential challenges: Authentication is a complex and delicate subject.
Some APIs require registration of special apps to "catch" authentication requests, while others simply provide an API key.
I will need to carefully navigate these complexities in the vignette.
- Changes:
- The vignette about configuring authentication was folded into the main package vignette, since it turned out to be surprisingly straightforward (at least at this point).
- At this point authentication covers API keys only.
- [x] **0.2.0: OAS definition discovery.**
- Proposal wording:
- Add support for APIs using the OAS json format.
- Streamline discovery of API definitions (with associated error handling).
- Potential challenges: There does not appear to be a set standard of where API definitions are posted on a given site.
It might be difficult to help users find the right place.
Interestingly, https://APIs.guru itself has a (simple) API to aid in API discovery, which might provide an opportunity to use api2r to generate parts of itself.
- Changes:
- API discovery was spun off to a separate package, [{anyapi}](https://anyapi.api2r.org).
- [x] **0.3.0: Batching and rate limiting.**
- Proposal wording:
- Add documentation for implementing batching and rate-limiting.
- If possible, export functionality to help implement these processes, but standards seem to vary widely.
- Potential challenges: This step will involve more reading and documenting than code, to gather examples of how different APIs implement limits and batching.
It's possible systems will be so different that it will be difficult to summarize them.
For example, Slack has two separate batching systems in its API, with some functions moved to the newer system, and others not.
- Changes:
- This was actually developed *after* 0.4.0.
- The wording I really wanted here was "pagination."
- This milestone resulted in the [pagination](pagination.html) vignette.
- [x] **0.4.0: Endpoint function scaffolding.**
- Proposal wording:
- Generate `R/*.R` and `tests/testthat/*.R` files for all endpoints ("paths") described in the given API specification.
- The generated functions will work, but error checking, documentation, and tests will be minimal.
- Potential challenges: I'll need to strike a balance here between getting a basic working system and producing something that can be easily expanded later.
- Changes:
- Generated `R/*.R` and `tests/testthat/*.R` files for all endpoints ("paths") described in the given API specification.
- The generated functions work, but error checking, documentation, and tests were minimal at this point.
- [ ] **0.5.0: More robust scaffolding.**
- Proposal wording:
- Add parameter documentation.
- Also add parameter type checking.
- Potential challenges: By this point I'll need an OAS definition document to use for testing that includes all of the possible parameter types.
I'll likely need to generate a fake API specification that goes beyond a typical individual example.
- Changes:
- Type checking is implemented for many parameter types (logical, character, integer, double), and infrastructure is in place to add the rest as they become available in the spun-off [{stbl}](https://stbl.wrangle.zone) package.
- I don't really *need* the grand API specification I envisioned for testing, so I did not create that.
- [ ] **0.6.0: Expected results.**
- Proposal wording:
- Add response (return value) documentation.
- Use expected responses to generate better test scaffolds.
- Potential challenges: Testing the generation of tests might present unique challenges.
I'll need to look into how testthat tests itself.
- [ ] **0.7.0: Error messaging.**
- Proposal wording:
- Add more robust error messaging for non-standard responses.
- Potential challenges: Mocking cases where things fail can be tricky.
Ideally this step will involve pushing the package to a stable 1.0.0, but that will require enough usage to feel confident that the core function definitions are stable.

I have plans beyond v0.7.0, logged as issues (and, in some cases, implemented infrastructure) in the GitHub repository.
For the moment, I am focusing on completing the expectations for the grant.
Loading