Naming: do we call it `core tidyverse` vs.?


Is there community consensus around what we call the packages that get loaded when we run library(tidyverse)? are they "core tidyverse"? What do we call other packages that are Tidy by Nature but not "core"?

So, for example, readxl is "part of the Tidyverse" (it says so on the readxl web site). But readxl does not get loaded when we library(tidyverse) ...

── Attaching packages ─────────────────────────────────────────────────────────────────────────────────── tidyverse 1.2.1 ──
:heavy_check_mark: ggplot2 2.2.1 :heavy_check_mark: purrr 0.2.4
:heavy_check_mark: tibble 1.4.2 :heavy_check_mark: dplyr 0.7.4
:heavy_check_mark: tidyr 0.8.0 :heavy_check_mark: stringr 1.3.0
:heavy_check_mark: readr 1.1.1 :heavy_check_mark: forcats 0.3.0


I call them non-core, but that's just me.

Usually, if I'm mentioning that a package is not part of the core tidyverse, I'm explaining that it will need to be attached with another library() call, and what that is, so it's not really a pithy context.


well looking at the documentation for readxl it says that it is loaded when you load the tidyverse... despite note being listed in the above output from library(tidyverse).... so maybe it is core? What about broom then? Mos def not "core" but Tidy by Nature.


I'm sorry, it sounded like you said, "Nerdcore"


Can you please file an issue for that in the readxl repo?


nevermind... the docs are right. I apparently read only every other line... I didn't realize that install.packages('tidyverse') installs more packages than are loaded by library('tidyverse')... now I realize the difference.


OK I just blurted this all over Twitter to try to stoke discussion. But there are really three buckets I'm trying to name:

  1. packages installed by install.packages('tidyverse')
  2. The subset loaded by library('tidyverse')
  3. Other Tidy packages

There's already momentum around calling the first group "The Tidyverse". And #3 is clearly "Tidy By Nature" (don't @ me)... so what's group 2 then?


The group to which I was referring as non-core.

We're definitely working on clarifying terminology, especially as group three proliferates (which is awesome, and also requires disambiguation at times when issues are filed, etc).


Ohhh... I see...

and this is obvious, but I was born with my --verbose flag permanently flipped on: the problem with dichotomous terms like core and non-core is we have more than two groups so that leads to ambiguity.



Not internal to the tidyverse, though. Group three (which isn't really a set of which we know the components) is not installed with the tidyverse (package), or part of the tidyverse, technically.


yeah... that makes sense...

so I guess there's:

  1. Tidyverse: All packages installed by install.packages('tidyverse')
  2. Tidyverse Core: packaged loaded by library(tidyverse)
  3. Tidyverse Non-Core: 1 - 2 (tidyverse packages not loaded by calling library(tidyverse) )
  4. Tidy By Nature: non Tidyverse packages which follow Tidy practices. (hip hop hooray)

So I think we've got that settled.


Right, though, as those aren't in/of the tidyverse, their respective authors might vary in the extent to which they perceive them as related…if that makes sense.


yeah, that group has to be pretty informal, I think. But I need a collective pronoun for the bucket, however non-homogeneous it may be.


however non-homogeneous it may be…

heterogenous, if you will :stuck_out_tongue_winking_eye:
/* said the girl who couldn't remember the word "doctor" and, thus, said she was going to the people vet */


I was mocked as a child for ordering a "hamburger with cheese" instead of a cheeseburger. It's getting worse as I age...


Why not just 'core' and 'more'?


So... on a related note, is magrittr Tidyverse Core? I thought it was, because pipes are ubiquitous. But today I tried to use extract2 and I discovered, much to my chagrin, that it was not available until I loaded magrittr... even though I had already loaded tidyverse ...

So is there a middle ground where a package is half-core? Is there a better way to describe this?



It is not. The ubiquitous pipe to which you have access in the core is imported in dplyr.

Personally, I don't think that adding a term to the mix for packages from which individual functions are imported would be terribly helpful. I don't know how many of the surrounding lines show up when you post a single-line permalink from GitHub these days, but there are definitely a few in there you'd be hard-up to describe in relationship to other tidyverse packages.


This makes perfect sense! Thank you so much, Mara.


Expanding a bit on @mara's answer:

dplyr (and many other tidyverse packages) import %>% from magrittr and rexport it for the user. Many of the tidyverse packages don't use %>% internally fwiw.

This treatment of %>% is so common in the tidyverse that it is implemented in usethis::use_pipe(). Typically this import-reexport treatment is only applied to %>%, i.e. not to any of the other functions or operators in magrittr.