`tune_grid()` fails if parameter is not marked as `tunable()` despite matching grid about tune HOT 4 OPEN

Wasn't sure whether to apply bug or feature, but either way, I agree that this ought to be fair game. :)

from tune.

Just to give another example with step_holiday(), whose holidays argument is not tunable.

library(tidyverse)
library(tidymodels)

examples <- data.frame(someday = ymd("2000-12-20") + days(0:40))

holiday_rec <- 
  recipe(~someday, examples) %>%
  step_holiday(all_predictors(), holidays = c("Easter", "ChristmasDay"))

There are 2^119 combinations of holidays (so make it tunable could be dangerous), but it would be nice if we could tune it based on a set of defined values, like this (as it's okay with list-columns now #633):

tibble(holidays = list(c("LaborDay", "NewYearsDay", "ChristmasDay"),
                       c("LaborDay", "NewYearsDay", "ChristmasDay", "Easter", "Annunciation"),
                       c("FRAllSaints", "FRBastilleDay", "FRAscension")))
# # A tibble: 3 × 1
#   holidays 
#   <list>   
# 1 <chr [3]>
# 2 <chr [5]>
# 3 <chr [3]>

Thanks!

from tune.

The example is motivated by tidymodels/dials#154

from tune.

A bit more context from poking at this for a moment...

tune_args() methods are intended to return arguments marked for tuning, tunable() methods are intended to return arguments marked for tuning that we can associated dials parameter information with. In some places, tune_args() methods more closely resemble tunable() methods, making it difficult for tune to handle custom grids in a principled way. In theory, if a user provides their own grid, then we should be able to rely only on tune_args() methods when running tune_grid(). In that case, tune_grid() takes care of collecting and then injecting each needed values and recipes and/or parsnip never need to know they're handling tuning parameters.

So, step 1 is to disambiguate tune_args() and tunable() in implementations. :)

from tune.