R Programming Quiz: Installing And Loading Packages
10 questions · exam conditions
0:00
Installing And Loading PackagesQuestion 1 of 10

A script creates a plot using only ggplot(), aes(), and geom_point(). The computer already has ggplot2 installed, but it does not have the tidyverse metapackage installed. The script begins with library(tidyverse) and stops with an error stating that there is no package called tidyverse.

Which change is the minimal correction needed to run the plotting code?

Replace the first line with library(ggplot2) and leave the plotting code unchanged.
Keep library(tidyverse) because installing ggplot2 also installs the metapackage.
Replace the first line with install.packages("ggplot2") and immediately call ggplot().
Replace the first line with library(geom_point) because that function creates the plotted layer.
← Back to quizzes

R Programming Quiz

R Programming Quiz: Installing And Loading Packages

Practice Installing And Loading Packages in R Programming with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Installing And Loading Packages, giving you a quick way to practice the rules, question types, and explanations that matter most for R Programming.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A script creates a plot using only ggplot(), aes(), and geom_point(). The computer already has ggplot2 installed, but it does not have the tidyverse metapackage installed. The script begins with library(tidyverse) and stops with an error stating that there is no package called tidyverse.

Which change is the minimal correction needed to run the plotting code?

  1. Replace the first line with library(ggplot2) and leave the plotting code unchanged. (correct answer)
  2. Keep library(tidyverse) because installing ggplot2 also installs the metapackage.
  3. Replace the first line with install.packages("ggplot2") and immediately call ggplot().
  4. Replace the first line with library(geom_point) because that function creates the plotted layer.
Explanation: When working with R packages, you need to distinguish between two separate actions: installing a package (downloading it to your computer) and loading it into your current R session with library(). You also need to understand the difference between a standalone package like ggplot2 and a metapackage like tidyverse, which is simply a collection of packages bundled together. In this scenario, ggplot2 is already installed on the machine — meaning all the functions you need (ggplot(), aes(), and geom_point()) are already available locally. The only problem is that the script tries to load tidyverse, which isn't installed. Since the plotting code only uses ggplot2 functions, the minimal fix is simply to load ggplot2 directly. That's exactly what A does — swapping library(tidyverse) for library(ggplot2) gives you access to everything the script needs without installing anything new. B is wrong because the relationship goes the other way: installing tidyverse installs ggplot2, not vice versa. Installing ggplot2 does nothing for tidyverse. C is a common trap — install.packages() downloads a package but doesn't load it into your session. You'd still need a library() call before using ggplot(), so this wouldn't work as written. D reflects a fundamental misunderstanding: geom_point is a function inside ggplot2, not its own package. There is no package called geom_point to load. A useful rule of thumb: always ask yourself, "Is the package installed? Is it loaded?" — these are two separate questions with two separate solutions.

Question 2

A package was installed from CRAN last week and remains in a directory listed by .libPaths(). The computer is now disconnected from the internet, and the user starts a fresh R session.

What should happen when the user runs library(digest)?

  1. It should work only if install.packages("digest") is rerun while offline.
  2. It should fail because library() verifies every installed package through CRAN.
  3. It should reinstall from the cached CRAN mirror before attaching the local package.
  4. It should load locally without contacting CRAN, assuming the installed package is usable. (correct answer)
Explanation: When you see a question about library() in R, you should be thinking about the distinction between installation and loading — two separate processes that operate independently of network connectivity. Once a package is installed, R stores it as compiled files in a local directory on your machine — exactly the kind of directory that .libPaths() lists. When you call library(digest), R simply searches those local directories, finds the package, and attaches it to your session. No internet connection is required, no CRAN verification occurs, and no re-download happens. This makes D the correct answer: the package loads locally as long as the installed files are intact and compatible with your R version. The distractors each represent a specific misconception worth understanding. A is wrong because install.packages() is only needed if the package isn't already installed — running it offline would actually fail, since installation does require downloading from CRAN. B describes a fictional behavior; library() does not "phone home" to CRAN on every call. It trusts the local installation completely. C invents a nonexistent caching mechanism — R doesn't silently reinstall packages before attaching them, and there's no automatic CRAN mirror cache that library() interacts with. A helpful mental model: think of install.packages() as downloading and placing a book on your shelf, and library() as simply picking that book up to read. Once it's on your shelf, you don't need the bookstore anymore. On exam questions involving offline or network scenarios, always ask yourself whether the operation requires a download or just accesses local files.

Question 3

A setup script must run on computers where digest may or may not already be installed. The script should avoid reinstalling an available package, but it must attach the package before later code uses its functions.

Which code best satisfies both requirements?

  1. Use library(digest); if (!requireNamespace("digest")) install.packages("digest") so that the package is attached first and installed afterward if it was missing.
  2. Use install.packages("digest"); library(digest) every time the setup script runs, ensuring the package is always current and attached.
  3. Use if (requireNamespace("digest", quietly = TRUE)) install.packages("digest") to reinstall when found and skip loading, relying on later code to attach it.
  4. Use if (!requireNamespace("digest", quietly = TRUE)) install.packages("digest"); library(digest) to install only when missing and then attach it. (correct answer)
Explanation: When writing setup scripts in R, you need to think about two distinct operations: installing a package (downloading it to disk) and attaching it (making its functions available via library()). A robust script should do both conditionally and in the right order. The pattern you want is: check first, install only if missing, then attach. requireNamespace("digest", quietly = TRUE) returns TRUE if the package is already available and FALSE if it isn't — crucially, without attaching it. So if (!requireNamespace(...)) install.packages(...) installs only when the package is absent. Following that with library(digest) unconditionally attaches the package regardless of whether it was just installed or already present. That's exactly what D does — it satisfies both requirements cleanly. A reverses the logic fatally: it calls library(digest) first, which will throw an error if the package isn't installed yet, making the installation check that follows unreachable and useless. B runs install.packages() unconditionally every time, which wastes time, triggers unnecessary downloads, and ignores whether the package is already present — violating the "avoid reinstalling an available package" requirement. C inverts the condition: if (requireNamespace(...)) triggers installation when the package is found, meaning it reinstalls unnecessarily and skips installation when the package is genuinely missing. It also never calls library(), so functions won't be attached for later code. As a study tip, remember this reliable R setup idiom: check with requireNamespace, install if ! found, then always attach with library() — in that exact order.

Question 4

A package is installed successfully with install.packages("RColorBrewer"). A later line, library(rcolorbrewer), reports that the package cannot be found, although the installation directory still contains it.

Which explanation and correction are most accurate?

  1. The package was installed but not compiled; use library(RColorBrewer, compile = TRUE).
  2. Installed packages require lowercase loading names; reinstall it as install.packages("rcolorbrewer").
  3. Package names are case-sensitive here; use library(RColorBrewer) with the installed capitalization. (correct answer)
  4. The package name must be quoted when it contains capitals; use library("rcolorbrewer").
Explanation: Whenever you see a question about loading R packages, the first thing to check is whether the name you're passing to library() exactly matches the name under which the package was installed — because R package names are case-sensitive. When you run install.packages("RColorBrewer"), R stores the package under the name RColorBrewer in your library directory. When you later call library(rcolorbrewer), R looks for a package named rcolorbrewer — which doesn't exist. The fix is simply to match the capitalization: library(RColorBrewer). That's why C is correct. Looking at the wrong answers: A invents a compile = TRUE argument that doesn't exist in library() — this is a fabricated option designed to sound plausible. Compilation happens during installation, not loading. B gets the logic exactly backwards; R doesn't require lowercase names, and reinstalling under a different (incorrect) capitalization would just create a broken or missing package. D introduces a real but irrelevant rule — quoting the name in library() is optional and equally valid with or without capitals. The actual problem isn't quotation marks; it's the mismatched capitalization, so library("rcolorbrewer") would still fail for the same reason as the original error. A good study habit here: treat R package names like passwords — copy them exactly as written in documentation or CRAN. When a library() call fails despite a successful install, your first instinct should always be to compare the capitalization character by character.

Question 5

An R script stores a package name in a variable and then uses that variable in both installation and loading code:

pkg <- "dplyr" install.packages(pkg) library(pkg)

Installation succeeds, but the final line reports that there is no package called pkg.

Which replacement for the final line correctly loads the package whose name is stored in pkg?

  1. Use library(pkg, character.only = TRUE) to interpret the variable's value. (correct answer)
  2. Use library(character.only = pkg) to pass the package name as an option.
  3. Use library("pkg") to convert the variable into a character package name.
  4. Use install.packages(pkg, character.only = TRUE) to install and attach it together.
Explanation: Whenever you see R code that stores a package name in a variable and then tries to load it, the key concept being tested is how library() handles its argument by default. Unlike install.packages(), which automatically treats its first argument as a character string, library() tries to interpret its argument as a literal name — so library(pkg) looks for a package literally named "pkg," not the value stored inside that variable. That's exactly why installation succeeds but loading fails. The fix is A: library(pkg, character.only = TRUE). The character.only parameter tells library() to evaluate the argument as a character string rather than treating it as a bare name. This forces R to look up the value stored in pkg — which is "dplyr" — and load that package instead. B is wrong because character.only is not a parameter that accepts a variable name as its value; it's a logical flag (TRUE or FALSE). Writing character.only = pkg passes a character string where a logical is expected, which is a misuse of the argument entirely. C is wrong because library("pkg") simply wraps the variable name in quotes, making it a string literal — R will now look for a package called "pkg", which is the same wrong behavior as the original problem. D is a distractor that muddles install.packages() with library() — installing a package does not attach it to your session, and install.packages() doesn't have a character.only parameter relevant here. As a study tip, remember that library() is uniquely strict about bare names — any time you're loading packages dynamically from variables, character.only = TRUE is your required flag.

Question 6

A user has attached version 1 of a package in the current session and wants to upgrade to version 2. The package's code may be in use, and the user wants the next calls to use only the upgraded version.

Which sequence is the safest general approach?

  1. Install version 2 while version 1 is attached and continue using the existing session.
  2. Call library() again before installation so it automatically switches versions afterward.
  3. Restart R, install version 2, and then run library() in the clean session. (correct answer)
  4. Remove version 1 while attached and call library() without installing version 2.
Explanation: When upgrading a loaded R package mid-session, the core challenge is that R locks shared library files on most operating systems and caches namespace environments in memory. Simply installing over an attached package doesn't guarantee the running session will use the new code — old function definitions may persist in the search path, and on Windows, the DLL may be physically locked, preventing installation entirely. The safest approach is C: restart R first to release all locks and clear the namespace cache, then install version 2 into a clean environment, and finally call library() to attach the fresh copy. This gives you a guaranteed, predictable state with no leftover artifacts from version 1. A is tempting but unreliable. Even if installation succeeds, the old namespace often remains attached in the same session. Functions you call afterward may still point to version 1's definitions until you explicitly detach and reattach — and even that can leave residual state. B is based on a misconception. Calling library() before installation doesn't prepare R to "auto-switch" versions. library() simply attaches whatever is currently installed; it has no awareness of a pending upgrade. D is actively harmful. Detaching a package with detach() or remove.packages() without having version 2 installed leaves you with no working package at all — you'd lose the functionality entirely rather than upgrading it. A good rule of thumb: treat package upgrades like database migrations — always start from a clean, known state. When you see upgrade scenarios on the exam, ask yourself whether the session state is truly clean before assuming a new install takes effect.

Question 7

A user successfully installed the readr package yesterday. Today, after starting a new R session, the user runs read_csv("sales.csv") and receives could not find function "read_csv".

Assuming the package remains installed, which change is the most appropriate fix?

  1. Run install.packages("readr") before every call to read_csv().
  2. Run library(readr) once near the beginning of the new session. (correct answer)
  3. Run library(read_csv) before attempting to read the data file.
  4. Run install.packages("read_csv") because functions are installed separately.
Explanation: Whenever you see an error like "could not find function," your first instinct should be to ask: is the package loaded, not just installed? In R, installing a package downloads it to your machine once, but it doesn't make its functions available automatically in future sessions. Each new R session starts fresh, and you must explicitly load any packages you need using library(). This is why B is correct. Running library(readr) at the top of your script attaches the package to your current session, making functions like read_csv() available for use. You only need to do this once per session, not before every function call. A is wrong because re-running install.packages("readr") before every call is unnecessary and wasteful — the package is already installed. Installation and loading are two separate steps; install.packages() handles the first, library() handles the second. C has the syntax backwards: library() takes a package name as its argument, not a function name. Writing library(read_csv) would throw an error because read_csv is a function inside the readr package, not a package itself. D reflects a fundamental misunderstanding — functions are not installed separately. They are bundled inside packages, and once the package is installed, all its functions become accessible when the package is loaded. A helpful mental model: think of installing a package as buying a toolbox and storing it in your garage. Running library() is how you bring that toolbox into your workshop each time you need it.

Question 8

A user installs a package into a nondefault library by running install.packages("digest", lib = "/opt/teamlib"). In a fresh R session, /opt/teamlib is not included in .libPaths().

Which command loads that installed copy without permanently changing .libPaths()?

  1. Run library(digest, lib.loc = "/opt/teamlib") to search that library directly. (correct answer)
  2. Run library("/opt/teamlib/digest") because library() accepts a package directory.
  3. Run install.packages("/opt/teamlib/digest") to register the existing package directory.
  4. Run library(digest) because installation automatically records every custom library path.
Explanation: When working with R packages, it's important to distinguish between where a package lives on disk and how R finds it at load time. R searches for packages using the paths listed in .libPaths(), but you can override that search on a per-call basis without touching the global path configuration. The library() function accepts an optional lib.loc argument that tells R exactly which directory to search for the package you're requesting. So running library(digest, lib.loc = "/opt/teamlib") points R directly at your team's custom library for that one call — the package loads successfully, and .libPaths() remains unchanged for the rest of the session. That's why A is correct. B is wrong because library() takes a package name, not a file path to a package directory. Passing a path string like "/opt/teamlib/digest" will cause R to look for a package literally named that string, which doesn't exist — you'll get an error. C is wrong because install.packages() is for downloading and installing packages, not for registering or "activating" an already-installed directory. Running it on a local path would attempt a reinstall from source, not a load. D is wrong because R does not automatically remember custom lib paths used during installation. Each fresh session only knows about the default paths in .libPaths() unless you explicitly specify otherwise. As a study tip, remember the pairing: install.packages(..., lib = ...) installs to a path, and library(..., lib.loc = ...) loads from a path — both accept the same directory, and neither permanently modifies .libPaths().

Question 9

In a fresh session, .libPaths() returns c("/project/lib", "/user/lib"). Version 1.0 of digest is installed in /project/lib, and version 2.0 is installed in /user/lib.

Which command specifically loads version 2.0 without first changing the order of .libPaths()?

  1. Run library(digest) because R always chooses the highest installed version.
  2. Run library(digest, lib.loc = "/user/lib") to search the second library. (correct answer)
  3. Run install.packages("digest") because installation selects the newest existing copy.
  4. Run library(digest, lib.loc = "/project/lib") to bypass the first search location.
Explanation: When loading a specific version of a package in R, the key concept to understand is how .libPaths() and the lib.loc argument interact. R searches library paths in order, loading the first match it finds — it does not automatically select the highest version number. So whenever multiple versions of a package exist across different libraries, you need to control where R looks. In this scenario, /project/lib comes first in .libPaths(), meaning a plain library(digest) call will find and load version 1.0 before ever reaching /user/lib. To bypass that default search order and target a specific directory, you use the lib.loc argument. library(digest, lib.loc = "/user/lib") tells R to look exclusively in /user/lib, where version 2.0 lives — making B the correct answer. A is wrong because R does not compare version numbers when loading packages. It simply loads the first match found along .libPaths(), which here would be version 1.0 from /project/lib. C is a red herring — install.packages() downloads and installs a package but does not load it into your session, and it certainly doesn't resolve which installed copy gets attached. D is backwards: pointing lib.loc to /project/lib would load version 1.0, the opposite of what you want. A useful pattern to remember: whenever you see a version-selection or library-path question, ask yourself "what does R search first, and how can lib.loc override that?" That single question will cut through most distractors on this topic.

Question 10

A user runs the following commands:

install.packages(c("dplyr", "stringr")) library(dplyr) str_detect(c("cat", "dog"), "a")

The final command reports that str_detect cannot be found.

Which additional command most directly resolves the error?

  1. Run install.packages("stringr") again because installation also attaches the package.
  2. Run library(stringr) because installing it did not attach its exported functions. (correct answer)
  3. Run library(c(dplyr, stringr)) because both packages must be attached simultaneously.
  4. Run library(str_detect) because the missing function must be loaded by name.
Explanation: Whenever you see a question about using R packages, keep two distinct steps in mind: installation and attachment. Installing a package (via install.packages()) downloads it to your machine, but it does NOT make its functions available in your current R session. To actually use a package's functions, you must separately attach it using library(). In this scenario, stringr was installed alongside dplyr, but only library(dplyr) was called afterward. Because stringr was never attached, R has no knowledge of str_detect in the active session — hence the error. Running library(stringr) is the direct fix, making B the correct answer. A is wrong because install.packages() strictly handles downloading and storing the package — it never attaches anything to your session. Running it again accomplishes nothing if the package is already installed and the real issue is attachment. C is wrong because library() does not accept a character vector of multiple package names the way install.packages() does. Calling library(c(dplyr, stringr)) will throw an error. You must call library() separately for each package. D is wrong because library() takes a package name as its argument, not a function name. str_detect is a function inside the stringr package — you load the package, not the individual function. A good rule of thumb: think of install.packages() as buying a book and putting it on your shelf, while library() is actually opening that book to read it. You need both steps every time you start a new R session.