Skip to content
Switch branches/tags

Latest commit

* Ensure that action removal retains remaining actions

* Implement `add_case_weights()` and friends

* Add extra tests for single action removal

* Add support for printing case weight info

* Mention issue number in NEWS bullet

* No need for `rlang::` prefix

* Pass the call through in `new_action_case_weights()`

* Add snapshot tests about case weights type

With suboptimal rlang call, but not sure we can improve that much right now

* Add snapshot test to ensure 1 column is selected

* Automatically detect `remove` based on the preprocessor type

* Require hardhat's case weights class

* Always use a named list for `actions`

This is slightly better for type stability

* Actually use the pre-stage constructor

Rather than overwriting the `$mold` slot directly. This allows the internal validation bits to actually run.

* Fix weird TODO typo

* Bump dev version to

* Use case weights branches of parsnip and recipes

* Pass case weights through to parsnip

* Add tests to ensure case weights are passed through to parsnip

Skipping a prediction time test for case weights + recipes for now. Currently hardhat requires that ALL roles are present at prediction time, rather than just outcome/predictor roles, which will be a better default.

* Use parsnip case weights PR

* Update tests now that hardhat has `bake_dependent_roles`

* Ensure that case weights are updated after processing the recipe

Since the recipe can potentially change the number of rows, meaning that our retained case weights vector could get out of sync. Handles the issue noted in #118 (comment)

* Bump parsnip/recipes dependencies to their dev versions

Git stats


Failed to load latest commit information.


Codecov test coverage R-CMD-check

What is a workflow?

A workflow is an object that can bundle together your pre-processing, modeling, and post-processing requests. For example, if you have a recipe and parsnip model, these can be combined into a workflow. The advantages are:

  • You don’t have to keep track of separate objects in your workspace.

  • The recipe prepping and model fitting can be executed using a single call to fit().

  • If you have custom tuning parameter settings, these can be defined using a simpler interface when combined with tune.

  • In the future, workflows will be able to add post-processing operations, such as modifying the probability cutoff for two-class models.


You can install workflows from CRAN with:


You can install the development version from GitHub with:

# install.packages("devtools")


Suppose you were modeling data on cars. Say…the fuel efficiency of 32 cars. You know that the relationship between engine displacement and miles-per-gallon is nonlinear, and you would like to model that as a spline before adding it to a Bayesian linear regression model. You might have a recipe to specify the spline:


spline_cars <- recipe(mpg ~ ., data = mtcars) %>% 
  step_ns(disp, deg_free = 10)

and a model object:

bayes_lm <- linear_reg() %>% 

To use these, you would generally run:

spline_cars_prepped <- prep(spline_cars, mtcars)
bayes_lm_fit <- fit(bayes_lm, mpg ~ ., data = juice(spline_cars_prepped))

You can’t predict on new samples using bayes_lm_fit without the prepped version of spline_cars around. You also might have other models and recipes in your workspace. This might lead to getting them mixed-up or forgetting to save the model/recipe pair that you are most interested in.

workflows makes this easier by combining these objects together:

car_wflow <- workflow() %>% 
  add_recipe(spline_cars) %>% 

Now you can prepare the recipe and estimate the model via a single call to fit():

car_wflow_fit <- fit(car_wflow, data = mtcars)

You can alter existing workflows using update_recipe() / update_model() and remove_recipe() / remove_model().


This project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.