<p><div><div><div><div data-show-faces="false" data-height="21" data-width="100" data-layout="button_count" data-send="true" data-href="https://www.r-bloggers.com/what-r-version-do-you-really-need-for-a-package/"></div></div><div></div></div><div></div></div>
<div>
(This article was first published on <strong><a href="https://www.jumpingrivers.com/blog/what-r-version-do-you-really-need-for-a-package/"> r – Jumping Rivers</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p>At <a rel="nofollow" href="https://www.jumpingrivers.com/" target="_blank">Jumping Rivers</a> we run a lot of R courses. Some of our most popular courses revolve around the <a rel="nofollow" href="https://www.tidyverse.org/" target="_blank">tidyverse</a>, in particular, our <a rel="nofollow" href="https://www.jumpingrivers.com/training/course/introduction-r-tidyverse/" target="_blank">Introduction to the tidyverse</a> and our more advanced <a rel="nofollow" href="https://www.jumpingrivers.com/training/course/r-tidyverse-purrr-broom/" target="_blank">mastering</a> course. We even trained over 200 data scientists NHS – see our <a rel="nofollow" href="https://www.jumpingrivers.com/case-study/project-1-training/" target="_blank">case study</a> for more details.</p>
<p>As you can imagine, when giving an on-site course, a reasonable question is what version of R is required for the course. We <strong>always</strong> have an RStudio cloud back-up, but it’s nice for participants to run code on their own laptop. If participants are to bring there own laptop it’s trivial for them to update R. But many of our clients are financial institutions or government where an upgrade is a non-trivial process.</p>
<p>So, what version of R is required for a <em>tidyverse</em> course? For the purposes of this blog post, we will define the list of packages we are interested in as</p>
<pre><code>library(&quot;tidyverse&quot;)
tidy_pkgs = c(&quot;ggplot2&quot;, &quot;purrr&quot;, &quot;tibble&quot;, &quot;dplyr&quot;, &quot;tidyr&quot;, &quot;stringr&quot;, 
         &quot;readr&quot;, &quot;forcats&quot;)
</code></pre>
<p>The code below will work with <strong>any</strong> packages of interest. In fact, you can set <code>pkgs</code> to all R packages in CRAN, it just takes a while.</p>
<h2>Package descriptions</h2>
<p>In R, there is a handy function called <code>available.packages()</code> that returns a matrix of details corresponding to packages currently available at one or more repositories. Unfortunately, the format isn’t initially amenable to manipulation. For example, consider the <strong>readr</strong> package</p>
<pre><code>readr_desc = available.packages() %>%
  as_tibble() %>%
  filter(Package == &quot;readr&quot;)
</code></pre>
<p>I immediately converted the data to a tibble, as that</p>
<ul>
<li>changed the rownames to a proper column</li>
<li>changed the matrix to a data frame/tibble, which made selecting easier</li>
</ul>
<p>Looking at the <code>read_desc</code>, we see that it has a minimum R version</p>
<pre><code>readr_desc$Depends 
## [1] &quot;R (>= 3.0.2)&quot;
</code></pre>
<p>but due to the format, it would be difficult to compare to R versions. Also, the list of imports</p>
<pre><code>readr_desc$Imports
## [1] &quot;Rcpp (>= 0.12.0.5), tibble, hms, R6&quot;
</code></pre>
<p>has a similar problem. For example, with the data in this format, it would be difficult to select packages that depend on <strong>tibble</strong>.</p>
<h2>Tidy package descriptions</h2>
<p>We currently have four columns</p>
<ul>
<li>Imports, Depends, Suggests, Enhances</li>
</ul>
<p>each entry in these columns contains multiple packages, with possible version numbers. To tidy the data set I’m going to create four new columns:</p>
<ul>
<li><code>depend_type</code>: one of Imports, Depends, Suggests, Enhances and LinkingTo</li>
<li><code>depend_package</code>: the package name</li>
<li><code>depend_version</code>: the package version</li>
<li><code>depend_condition</code>: something like equal to, less than or greater than</li>
</ul>
<p>The hard work is done by the function <code>clean_dependencies()</code>, which is at the end of the blog post. It essentially just does a bit of string manipulation to separate out the columns. The function works per package, so we iterate over packages using <code>map_df()</code></p>
<pre><code>pkg_deps = c(&quot;Depends&quot;, &quot;Enhances&quot;, &quot;Suggests&quot;, &quot;Imports&quot;, &quot;LinkingTo&quot;)
av_pkgs = available.packages() %>%
  as_tibble()

av_pkgs = map_df(pkg_deps, clean_dependencies, av_pkgs = av_pkgs) %>% 
  select(-pkg_deps)

# Std version: 3.4 -> 3.4.0
av_pkgs = av_pkgs %>%
  mutate(depend_version = if_else(depend_package == &quot;R&quot;, 
                                  clean_r_ver(depend_version),
                                  depend_version))

# Standardise column names
colnames(av_pkgs) = str_to_lower(colnames(av_pkgs))
</code></pre>
<p>After this step, we now have tibble with tidy columns:</p>
<pre><code>av_pkgs %>%
  select(package, depend_type, depend_package, depend_version, depend_condition) %>%
  slice(1:4)

## # A tibble: 4 x 5
##   package  depend_type depend_package depend_version depend_condition
##   </code></pre>