handle quasi-likelihood glmnet models better

[topepo]

Similar to tidymodels/parsnip#483

library(tidymodels)
#> Registered S3 method overwritten by 'tune':
#>   method                   from   
#>   required_pkgs.model_spec parsnip
library(poissonreg)

n <- 2e3
set.seed(123)
x1 <- MASS::rnegbin(n, mu = 28, theta = 0.6)
x2 <- rnorm(n, 5, 10)
x3 <- as.factor(rnorm(n) < 0)
y <- as.integer(x1 + x2 + as.numeric(x3))
y[y < 0] <- 0
data <- tibble(y, x1, x2, x3)

poisson_reg(penalty = 0.5) %>% 
  set_engine("glmnet") %>% 
  fit(y ~ x1 + x2, data = data) %>% 
  pluck("fit") %>% 
  class()
#> [1] "fishnet" "glmnet"

# 'fishnet' is their class of Poisson models

poisson_reg(penalty = 0.5) %>% 
  set_engine("glmnet", family = quasipoisson()) %>% 
  fit(y ~ x1 + x2, data = data) %>% 
  pluck("fit") %>% 
  class()
#> [1] "glmnetfit" "glmnet"

# Now the class is not Poisson specific, so our methods don't know what to do

^{Created on 2021-05-04 by the reprex package (v1.0.0.9000)}

We should add class to the parsnip model or restrict this family for this engine.

[hfrick]

@topepo do you have a preference between the two options? I tend towards trying to avoid restricting the family but I guess that means adding running glmnet-specific code in parsnip::fit.model_spec() (in these lines) and parsnip::fit_xy.model_spec()

If we make the changes in parsnip, we might not need to touch the extension packages with glmnet engines

[hfrick]

I think this needs handling in parsnip (and testing in extratests):

Because all base-R family objects get the glmnetfit class and parsnip already defines the methods for them, we'd just overwrite those methods here. So we'd either need to extend them or break something for parsnip itself. So we might as well extend them in parsnip, especially since we are possibly running into this again with censored?

https://github.com/tidymodels/parsnip/blob/2f3ef6013111b6df271f464918130c222ccbd94e/R/glmnet-engines.R#L115-L128

If so, we should also move the issue.