Skip to content

Export prepare_*() functions #101

@jonthegeek

Description

@jonthegeek

Summary

As a maintainer of an API-wrapping R package, in order to develop specific aspects of my package one piece at a time, I would like to directly call the generate_pkg() helper functions.

Details

Export these functions. The inputs to each function will have to change to mostly match (a subset of) the inputs to generate_pkg(). For example, this should be the signature of generate_pkg_auth():

generate_pkg_auth(
  api_abbr = read_api_abbr(pkg_dir, config_filename),
  security_schemes = read_security_schemes(
    pkg_dir,
    read_rapid_filename(pkg_dir, config_filename)
  ),
  save_security_data = TRUE,
  security_data_filename = "_beekeeper_security.yml",
  config_filename = "_beekeeper.yml",
  pkg_dir = "."
)

And this should be the signature of the read_security_schemes() helper (which will use read_api_definition() to read the api_definition, then extract the api_definition@components@security_schemes:

read_security_schemes(
  pkg_dir = ".",
  rapid_filename = read_rapid_filename(pkg_dir)
)

Exported functions (each of which might have a helper or helpers for reading their inputs, similar to read_security_schemes(); all of these read helpers go in R/read_config.R):

  • generate_pkg_auth() (from .generate_security(); also rename R/generate_pkg-security.R to R/generate_pkg_auth.R, and rename its tests and its snapshots similarly). Add two arguments: save_security_data = TRUE and security_data_filename = "_beekeeper_security.yml" (or maybe _beekeeper_security.rds; I think security_data can always "fit" nicely in yml, but decide that based on the test data as you implement this feature). When save_security_data is true, save the security_data to security_data_filename (within the pkg_dir), and update config_file to add a security_data_filename field. Also export a read_security_schemes() helper, as described above. Note: I'm trying to differentiate between the "auth" functions (what we generate) and the "security data" (what the api_definition holds, from the OpenAPI schema).
  • generate_pkg_req_prepare() (from .generate_prepare(); also rename R/generate_pkg-prepare.R to R/generate_pkg_req_prepare.R, and rename its tests and its snapshots similarly). We don't need/want to save anything extra here, since it just returns its generated paths.
  • generate_pkg_paths() (from .generate_paths(); also rename R/generate_pkg-paths.R to R/generate_pkg_paths.R, and rename its tests and its snapshots similarly). We don't need/want to save anything extra here, since it just returns its generated paths.
  • generate_pkg_shared_params() (from .generate_shared_params(); also rename R/generate_pkg-shared.R to R/generate_pkg_shared.R, and rename its tests and its snapshots similarly). We don't need/want to save anything extra here, since it just returns its generated paths.

We'll also need to call .setup_r() (or, rather, equivalent helpers) from each of these to make sure we're working in a directory that's ready for everything. Have each generate_pkg_*() call the appropriate helpers defined in R/generate_pkg-setup.R to prepare for what it needs. Split .setup_r() into smaller helpers (similar to what I already did with .use_package() and .maybe_use_stbl()), and likely eliminate the single .setup_r() altogether (since generate_pkg() will no longer need to call it and will instead delegate the setup steps to generate_pkg_*()).

Note: We will not yet export a version of .generate_pagination(), since that's just a stub right now.

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions