Skip to content

Commit 312d191

Browse files
authored
unexport checking helpers (#809)
1 parent 00cd2c2 commit 312d191

File tree

3 files changed

+35
-114
lines changed

3 files changed

+35
-114
lines changed

NAMESPACE

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -247,7 +247,6 @@ export(predict_time)
247247
export(predict_time.model_fit)
248248
export(prepare_data)
249249
export(print_model_spec)
250-
export(prompt_missing_implementation)
251250
export(proportional_hazards)
252251
export(rand_forest)
253252
export(repair_call)
@@ -273,8 +272,6 @@ export(show_call)
273272
export(show_engines)
274273
export(show_fit)
275274
export(show_model_info)
276-
export(spec_is_loaded)
277-
export(spec_is_possible)
278275
export(stan_conf_int)
279276
export(surv_reg)
280277
export(survival_reg)

R/misc.R

Lines changed: 35 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -54,43 +54,39 @@ mode_filter_condition <- function(mode, user_specified_mode) {
5454
rlang::quo(mode == !!mode)
5555
}
5656

57-
#' @section Model Specification Checking:
58-
#'
59-
#' The helpers `spec_is_possible()`, `spec_is_loaded()`, and
60-
#' `prompt_missing_implementation()` provide tooling for checking
61-
#' model specifications. In addition to the `spec`, `engine`, and `mode`
62-
#' arguments, the functions take arguments `user_specified_engine` and
63-
#' `user_specified_mode`, denoting whether the user themselves has
64-
#' specified the engine or mode, respectively.
65-
#'
66-
#' `spec_is_possible()` checks against the union of
67-
#'
68-
#' * the current parsnip model environment and
69-
#' * the `model_info_table` of "pre-registered" model specifications
70-
#'
71-
#' to determine whether a model is well-specified. See
72-
#' `parsnip:::read_model_info_table()` for this table.
73-
#'
74-
#' `spec_is_loaded()` checks only against the current parsnip model environment.
75-
#'
76-
#' `spec_is_possible()` is executed automatically on `new_model_spec()`,
77-
#' `set_mode()`, and `set_engine()`, and `spec_is_loaded()` is executed
78-
#' automatically in `print.model_spec()`, among other places. `spec_is_possible()`
79-
#' should be used when a model specification is still "in progress" of being
80-
#' specified, while `spec_is_loaded` should only be called when parsnip or an
81-
#' extension receives some indication that the user is "done" specifying a model
82-
#' specification: at print, fit, addition to a workflow, or `extract_*()`, for
83-
#' example.
84-
#'
85-
#' When `spec_is_loaded()` is `FALSE`, the `prompt_missing_implementation()`
86-
#' helper will construct an informative message to prompt users to load or
87-
#' install needed packages. It's `prompt` argument refers to the prompting
88-
#' function to use, usually [cli::cli_inform] or [cli::cli_abort], and the
89-
#' ellipses are passed to that function.
90-
#'
91-
#' @export
92-
#' @keywords internal
93-
#' @rdname add_on_exports
57+
# Model Specification Checking:
58+
#
59+
# The helpers `spec_is_possible()`, `spec_is_loaded()`, and
60+
# `prompt_missing_implementation()` provide tooling for checking
61+
# model specifications. In addition to the `spec`, `engine`, and `mode`
62+
# arguments, the functions take arguments `user_specified_engine` and
63+
# `user_specified_mode`, denoting whether the user themselves has
64+
# specified the engine or mode, respectively.
65+
#
66+
# `spec_is_possible()` checks against the union of
67+
#
68+
# * the current parsnip model environment and
69+
# * the `model_info_table` of "pre-registered" model specifications
70+
#
71+
# to determine whether a model is well-specified. See
72+
# `parsnip:::read_model_info_table()` for this table.
73+
#
74+
# `spec_is_loaded()` checks only against the current parsnip model environment.
75+
#
76+
# `spec_is_possible()` is executed automatically on `new_model_spec()`,
77+
# `set_mode()`, and `set_engine()`, and `spec_is_loaded()` is executed
78+
# automatically in `print.model_spec()`, among other places. `spec_is_possible()`
79+
# should be used when a model specification is still "in progress" of being
80+
# specified, while `spec_is_loaded` should only be called when parsnip or an
81+
# extension receives some indication that the user is "done" specifying a model
82+
# specification: at print, fit, addition to a workflow, or `extract_*()`, for
83+
# example.
84+
#
85+
# When `spec_is_loaded()` is `FALSE`, the `prompt_missing_implementation()`
86+
# helper will construct an informative message to prompt users to load or
87+
# install needed packages. It's `prompt` argument refers to the prompting
88+
# function to use, usually [cli::cli_inform] or [cli::cli_abort], and the
89+
# ellipses are passed to that function.
9490
spec_is_possible <- function(spec,
9591
engine = spec$engine,
9692
user_specified_engine = spec$user_specified_engine,
@@ -119,10 +115,7 @@ spec_is_possible <- function(spec,
119115
return(nrow(possibilities) > 0)
120116
}
121117

122-
# see ?add_on_exports for more information on usage
123-
#' @export
124-
#' @keywords internal
125-
#' @rdname add_on_exports
118+
# see notes above spec_is_possible for more information on usage
126119
spec_is_loaded <- function(spec,
127120
engine = spec$engine,
128121
user_specified_engine = spec$user_specified_engine,
@@ -160,10 +153,7 @@ is_printable_spec <- function(x) {
160153
# if there's a "pre-registered" extension supporting that setup,
161154
# nudge the user to install/load it.
162155
#
163-
# see ?add_on_exports for more information on usage
164-
#' @export
165-
#' @keywords internal
166-
#' @rdname add_on_exports
156+
# see notes above spec_is_possible for more information on usage
167157
prompt_missing_implementation <- function(spec,
168158
engine = spec$engine,
169159
user_specified_engine = spec$user_specified_engine,

man/add_on_exports.Rd

Lines changed: 0 additions & 66 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

0 commit comments

Comments
 (0)