install_github() does not enforce remotes dependency

[clauswilke]

For my ggtext package, I find myself fielding tons of bug reports where people are not running the latest development version of ggplot2 (e.g.: wilkelab/ggtext#13 wilkelab/ggtext#14 wilkelab/ggtext#21). However, I have correctly specified ggplot2 in remotes.

What I think is happening is that when people run remotes::install_github("wilkelab/ggtext"), they are given the option to not install the development version of ggplot2, and there is no indication that that may cause problems. The following screenshot indicates what it looks like from an enduser's perspective.

I'm not sure what the best approach would be, but at a minimum there should be some sort of indication that not upgrading ggplot2 may cause trouble.

[clauswilke]

Thinking some more about this, I probably should set a proper version restriction on the ggplot2 dependency, but the issue remains. Now the install fails, but the problem is hidden in a bunch of error messages and there is no easy way to see that it was caused by my choice to not upgrade packages.

> remotes::install_github("wilkelab/ggtext")
Downloading GitHub repo wilkelab/ggtext@master
These packages have more recent versions available.
Which would you like to update?

 1: All                                         
 2: CRAN packages only                          
 3: None                                        
 4: ggplot2    (3.2.1  -> b43435119...) [GitHub]
 5: rlang      (0.4.3  -> 0.4.4       ) [CRAN]  
 6: digest     (0.6.23 -> 0.6.24      ) [CRAN]  
 7: mime       (0.8    -> 0.9         ) [CRAN]  
 8: rstudioapi (0.10   -> 0.11        ) [CRAN]  
 9: callr      (3.4.1  -> 3.4.2       ) [CRAN]  
10: processx   (3.4.1  -> 3.4.2       ) [CRAN]  
11: ps         (1.3.0  -> 1.3.1       ) [CRAN]  

Enter one or more numbers, or an empty line to skip updates:

✓  checking for file ‘/private/var/folders/b1/13gn4j655jddkfhxmtk5tsfm0000gn/T/Rtmp9ybHkS/remotes166ef9694c8f/wilkelab-ggtext-24e9cd0/DESCRIPTION’ ...
─  preparing ‘ggtext’:
✓  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  building ‘ggtext_0.1.0.tar.gz’
   
* installing *source* package ‘ggtext’ ...
** using staged installation
** R
** byte-compile and prepare package for lazy loading
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) : 
  namespace ‘ggplot2’ 3.2.1 is being loaded, but >= 3.3.0 is required
Calls: <Anonymous> ... withCallingHandlers -> loadNamespace -> namespaceImport -> loadNamespace
Execution halted
ERROR: lazy loading failed for package ‘ggtext’
* removing ‘/Library/Frameworks/R.framework/Versions/3.6/Resources/library/ggtext’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/3.6/Resources/library/ggtext’
Error: Failed to install 'ggtext' from GitHub:
  (converted from warning) installation of package ‘/var/folders/b1/13gn4j655jddkfhxmtk5tsfm0000gn/T//Rtmp9ybHkS/file166ef6021451c/ggtext_0.1.0.tar.gz’ had non-zero exit status
>

[jimhester]

There is not much to be done about this unfortunately, if you want to you can list your install instructions as remotes::install_github("wilkelab/ggtext", upgrade = "always").

[clauswilke]

I think there are ways to improve the situation. This is a user interface issue, so you could do one or more of the following:

1. Put "(recommended)" after "All"
2. Scan the dependency requirements and print a list of required upgrades. As in: "These packages require upgrading: ggplot2" (Then I would see immediately that the required ggplot2 is not on CRAN)
3. Inform the user when "Remotes" are set. E.g., write something like: "Installation may require non-CRAN versions of these packages: ggplot2"

Of these, I like the second the most. It makes it clear whether upgrading packages is optional or required.

[jimhester]

Unfortunately all of these options would require non-trivial amounts of refactoring of the current code and I unfortunately don't have the time to do so.

This isn't an issue particular to the Remotes: field either, the same issues would arise if a package depended on a newer version of a CRAN package.

If people willfully decline to update packages it is on them to debug the subsequent failures. The only way you can be absolutely sure you have the proper versions is to upgrade all dependencies to the latest versions.

[clauswilke]

Wouldn't my option 1 only require a simple string replacement from "All" to "All (recommended)" in these two lines:

remotes/R/deps.R

Line 592 in f1270b6

choices <- c("All", "CRAN packages only", "None", choices)

remotes/R/deps.R

Line 601 in f1270b6

if ("All" %in% res) {

If I got this right, I'm happy to prepare a PR.

I understand that it's not worth it to do a major refactoring of the code, but if there's a small modification to the message the user sees that may guide novice users, I think that's a worthwhile improvement.

[jimhester]

Ok, I agree with you about #1!

Though I am somewhat concerned about the wording, as some people might misinterpret All (recommended) to mean updating all 'recommended' packages. 'All (suggested)' has similar problems...

[clauswilke]

How about changing the menu title? After "Which would you like to update?", it could say something like "(It is usually best to update all)" or "(We recommend to update all)".

[jimhester]

Yep, that is what I ended up doing in 092e56a

[clauswilke]

Super, thanks! In this way, if people get strange errors, at least they may remember that they didn't follow the recommendation.