Deprecate bootstrap_dependencies() and use bslib as default instead

[apreshill]

(to discuss)

@cpsievert After discussion, we are considering adding bslib as a dependency for rmarkdown. Looking at the dependencies, there is a lot of overlap, but we were wondering about the magrittr dependency: https://github.com/rstudio/bslib/blob/master/DESCRIPTION#L28

We didn't see anything clear in the bslib docs on using magrittr with bslib- might that be moved to suggests instead? Or are there other use cases? Thanks!

[cpsievert]

Yea, I can likely move magrittr to a suggestion in the next release

[cderv]

I was curious about the relation about rmarkdown and magrittr so I looked it up.
Let's just know that magrittr is already a package that will be installed with rmarkdown thought the use of stringr. https://github.com/tidyverse/stringr/blob/f030ae09b96e6815e16e257bad69c735530a2479/DESCRIPTION#L26

> pak::pkg_deps_explain("rmarkdown", "magrittr")
rmarkdown -> knitr -> stringr -> magrittr                                 
rmarkdown -> stringr -> magrittr

But it seems indeed that bslib does not really need magrittr has a hard dependency so it would be best to move it to soft dep if possible.

[yihui]

IMHO infrastructure packages like bslib and stringr shouldn't be so opinionated about users' coding style (to pipe or not). This decision should be left to users (i.e., if they like pipes, they can always load magrittr by themselves), rather than being enforced at the package level (i.e., making magrittr a hard dependency).

FWIW the dependency on stringr might be removed someday (yihui/knitr#1549).

[cderv]

Same as in bslib, I don't think this is used directly in the package. I believe this reexported by convenience in the tidyverse to have the operator loaded in the session when stringr is loaded without to have to load magrittr explicitly. But this is a low level package with no dependency, so it do no harm to have it available with those package without needing to add library(magrittr) everytime you need the pipe.

But I see and understand your argument for package outside the tidyverse ecosystem (which itself use the pipe exetensively by design I think)

[yihui]

On one hand, I have no problem with higher-level packages being opinionated. On the other hand, bslib doesn't belong to the tidyverse, hence it doesn't have to be as opinionated as tidyverse in terms of users' coding style. In addition, R has got the new native pipe |> now, so it makes even less sense for bslib to play the role of deciding for users which pipe to use.

[apreshill]

Adding [TODOs] here:

1. Deprecation strategy then needed for the existing exported Bootstrap dependency (https://pkgs.rstudio.com/rmarkdown/reference/html-dependencies.html)

   • Deprecate with warning and a message

   • Check for CRAN rev deps

2. Decision needed: which version of Bootstrap should be the default- 3 or 4?

[cderv]

FWIW bslib version 0.3.0 is out with dependencies removed.

Deps tree of bslib is now:

> pak::pkg_deps_tree("bslib")
bslib 0.3.0 [new]
+-htmltools 0.5.2 [new]
| +-digest 0.6.27 [new][dl] (268.58 kB)
| +-base64enc 0.1-3 [new]
| +-rlang 0.4.11 [new][dl] (1.19 MB)
| \-fastmap 1.1.0 [new][dl] (215.42 kB)
+-jsonlite 1.7.2 [new][dl] (544.22 kB)
+-sass 0.4.0 [new][dl] (3.64 MB)
| +-fs 1.5.0 [new][dl] (605.11 kB)
| +-rlang
| +-htmltools
| +-R6 2.5.1 [new][dl] (84.27 kB)
| \-rappdirs 0.3.3 [new][dl] (58.75 kB)
+-jquerylib 0.1.4 [new][dl] (525.79 kB)
| \-htmltools
\-rlang

Decision needed: which version of Bootstrap should be the default- 3 or 4?

Bootstrap 5 will be the default in next bslibrelease probably. So choice will be default to 3 or 5 maybe...