Repository navigation
Deprecate bootstrap_dependencies() and use bslib as default instead #2154
Description
Activity
Yea, I can likely move magrittr to a suggestion in the next release
Reacted by Yihui Xie, Christophe Dervieux and Alison Presmanes HillI 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.
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).
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)
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.Reacted by Christophe DervieuxAdding [TODOs] here:
-
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
-
-
Decision needed: which version of Bootstrap should be the default- 3 or 4?
-
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...
- added 2 commits that reference this issue
on Sep 17, 2021 - added a commit that references this issue
on Sep 27, 2021 - changed the title
[-][FR] Consider adding bslib an explicit default dependency[/-][+]Deprecate `bootstrap_dependencies()` and use bslib as default instead[/+]on Dec 23, 2021 - added a commit that references this issue
on May 5, 2022 - added a commit that references this issue
on May 11, 2026 - added a commit that references this issue
on May 14, 2026
(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
magrittrdependency: https://github.com/rstudio/bslib/blob/master/DESCRIPTION#L28We didn't see anything clear in the bslib docs on using
magrittrwith bslib- might that be moved to suggests instead? Or are there other use cases? Thanks!