Update dependencies-mindset-background.Rmd (#1019)

Fixed spelling and grammatical errors, and enhanced clarity.

dependencies-mindset-background.Rmd

@@ -11,7 +11,7 @@ But that still leaves many issues for you to think about:
 -   When should you take a dependency?
     What are the risk and rewards?
     In @sec-dependencies-pros-cons we provide a framework for deciding whether a dependency is worth it.
-    This chapter also includes specific sections for deciding between `Imports` and `Suggests` (@sec-dependencies-imports-vs-suggests) and between Imports and `Depends` (@sec-dependencies-imports-vs-depends).
+    This chapter also includes specific sections for deciding between `Imports` and `Suggests` (@sec-dependencies-imports-vs-suggests) and between `Imports` and `Depends` (@sec-dependencies-imports-vs-depends).
 
 -   How should you use different kinds of dependencies in different contexts?
     I.e. imported vs. suggested packages, used inside your functions vs tests vs documentation.
@@ -39,7 +39,7 @@ We feel that this is bad advice for most projects, and is likely to lead to lowe
 
 ### Dependencies are not equal
 
-One problem with simply minimizing the absolute number of dependencies is that it treats all dependencies as equivalent, as if they all have the same costs and benefits (or even, infinite cost and no benefit).
+One problem with simply minimizing the absolute number of dependencies is that it treats all dependencies as equivalent, as if they all have the same costs and benefits (or even, infinite costs and no benefits).
 However, in reality, this is far from the truth.
 There are many axes upon which dependencies can differ, but some of the most important include:
 
@@ -100,8 +100,8 @@ If the audience is other package authors, then a leaner package with fewer depen
 If, instead, the target user is a data scientist or statistician, they will likely already have many popular dependencies installed and would benefit from a more feature-full package.
 
 A balanced approach understands that adding (or removing) dependencies comes with trade-offs.
-Adding a dependency gives you additional features, bug fixes, and real-world testing, at the cost of increased installation time, disk space and maintenance, if the dependency has breaking changes.
-In some cases it makes sense to *increase* dependencies for a package, even if an implementation already exists.
+Adding a dependency gives you additional features, bug fixes, and real-world testing, at the cost of increased installation time, disk space, and maintenance, if the dependency has breaking changes.
+In some cases, it makes sense to *increase* dependencies for a package, even if an implementation already exists.
 For instance, base R has a number of different implementations of non-standard evaluation with varying semantics across its functions.
 The same used to be true of tidyverse packages as well, but now they all depend on the implementations in the [tidyselect](https://tidyselect.r-lib.org) and [rlang](https://rlang.r-lib.org) packages.
 Users benefit from the improved consistency of this feature and individual package developers can let the maintainers of tidyselect and rlang worry about the technical details.
@@ -205,7 +205,7 @@ N  checking package dependencies (1.5s)
 ```
 
 Our best advice is to try hard to comply, as it should be rather rare to need so many dependencies and it's best to eliminate any `NOTE` that you can.
-Of course, there are exceptions to every rule and perhaps your package is one them.
+Of course, there are exceptions to every rule, and perhaps your package is one of them.
 In that case, you may need to argue your case.
 It is certainly true that many CRAN packages violate this threshold.
 :::
@@ -238,7 +238,7 @@ In that case, withr should be listed in `Imports`.
 `Suggests` isn't terribly relevant for packages where the user base is approximately equal to the development team or for packages that are used in a very predictable context.
 In that case, it's reasonable to just use `Imports` for everything.
 Using `Suggests` is mostly a courtesy to external users or to accommodate very lean installations.
-It can free users from downloading rarely needed packages (especially those that are tricky to install) and lets them get started with your package as quickly as possible.
+It can free users from downloading rarely-needed packages (especially those that are tricky to install) and lets them get started with your package as quickly as possible.
 
 ## Namespace {#sec-dependencies-namespace}
 
@@ -358,8 +358,8 @@ For now, we just lay out the reasons we prefer this method of generating the `NA
     This organization also makes Git diffs much more informative.
 
 Note that you can choose to use roxygen2 to generate just `NAMESPACE`, just `man/*.Rd` (@sec-man), or both (as is our practice).
-If you don't use any namespace related tags, roxygen2 won't touch `NAMESPACE`.
-If you don't use any documentation related tags, roxygen2 won't touch `man/`.
+If you don't use any namespace-related tags, roxygen2 won't touch `NAMESPACE`.
+If you don't use any documentation-related tags, roxygen2 won't touch `man/`.
 
 ## Search path {#sec-dependencies-search}
 
@@ -402,7 +402,7 @@ The first environment (the global environment) and the last two (`Autoloads` and
 
 But the middle section of attached packages is more dynamic.
 When a new package is attached, it is inserted right after and becomes the parent of the global environment.
-When you attach another package with `library()`, it changes the search path, as show in @fig-search-path-insertion:
+When you attach another package with `library()`, it changes the search path, as shown in @fig-search-path-insertion:
 
 ```{r}
 #| label: fig-search-path-insertion
@@ -435,7 +435,7 @@ Every function in a package is associated with a pair of environments: the packa
 
 -   The package environment is the external interface to the package.
     It's how a regular R user finds a function in an attached package or with `::`.
-    Its parent is determined by search path, i.e. the order in which packages have been attached.
+    Its parent is determined by the search path, i.e. the order in which packages have been attached.
     The package environment only exposes exported objects.
 
 -   The namespace environment is the internal interface of the package.
@@ -569,7 +569,7 @@ See @sec-code-onLoad-onAttach for some use cases for `.onLoad()` and `.onAttach(
 
 ### Whether to Import or Depend {#sec-dependencies-imports-vs-depends}
 
-We are now in a position to lay out the difference between between `Depends` and `Imports` in the `DESCRIPTION`.
+We are now in a position to lay out the difference between `Depends` and `Imports` in the `DESCRIPTION`.
 Listing a package in either `Depends` or `Imports` ensures that it's installed when needed.
 The main difference is that a package you list in `Imports` will just be *loaded* when you use it, whereas a package you list in `Depends`will be *attached* when your package is attached.