Move more dependencies to Suggests

[jimhester]

This allows devtools to be installed in less time, such as when it is
used only to install packages and dependencies on Travis and other CIs.

If a given Suggested dependency is needed for functionality check_suggested() prints an informative error

check_suggested("ggplot22")
#> Error: 'ggplot22' must be installed for this functionality
check_suggested("ggplot2", "2.0.0")
#> Error: 'ggplot2' >= 2.0.0 must be installed for this functionality

This should remove the Rcpp dependency and combined with r-lib/httr@7c68198 it should lighten the dependency load for devtools considerably.

[hadley]

This check could now go

[hadley]

Where does evaluate get used? In run_examples() maybe?

[hadley]

The only package I'm hesitant about removing is roxygen2, because I have some vague recollection that we deliberately made it part of devtools. I think it's basically because there's a strong tension in devtools to be batteries included because it makes teaching R package development that much easier.

[jimhester]

Evaluate is from run_examples(), I had a check for it, but failed to save that file, included in 9fc052f.

Also removed the extra Rcpp check in 8b94cf4.

Unfortunately roxygen2 has dependencies for both stringr and Rcpp, which are the two biggest dependencies for devtools currently, so keeping it in Imports kind of defeats the purpose of this PR.

I agree with the batteries included approach to devtools, it just doesn't jive well when it is used for installing packages on CIs. You could always suggest people install devtools with install.packages("devtools", dependencies = TRUE) to install all the Suggested packages (including roxygen2).

The best solution would be to split out the install_ functions to their own package (installr?), which would have limited dependencies, but for now I guess this is a stop gap.

[hadley]

Another option would be to have a batteriesincluded package that just had everything people needed as a dependency.

[hadley]

For symmetry if we're going to drop roxygen2, I think we should also drop testhat.

And could you add a bullet point to NEWS and think about how to change the README to tell people how to get a full environment for package development?

[gaborcsardi]

Whenever ppl try using testthat or roxygen, they could just get a message that it is missing, and it needs to be installed. Potentially devtools could also install them if interactive().

Btw. as much as I like micropackages, I personally don't like "removing" testthat and roxygen2.
Maybe we can work on making roxygen2 lighter, e.g. remove the Rcpp dependency. testthat is not too heavy imo. And/or moving the install_* functions to separate packages.

Btw.2. slightly related, https://github.com/metacran/description is almost ready. Some more docs would be nice, and validation is mostly missing. Validation is very hard, actually, for some fields, e.g. License. I'll add them, slowly, but it will take a while.

[jimhester]

Actually testthat has nearly always been in Suggests (0a02d83) and is only used for test(), which we check for https://github.com/hadley/devtools/pull/962/files#diff-576140fd16c657af5df5c401b5f95bbbR21, so that should be OK.

The main issues with just using install.packages("devtools", dependencies = TRUE) is

1. BiocInstaller, because you can't install that from CRAN (and most people aren't going to need it)
2. Rcpp (not needed if you are doing R only) and Windows users often don't have a RTools installed.
3. lintr - many people aren't going to use this, has a hefty igraph dependency (although it wouldn't hurt it's popularity 😄)
4. MASS and bitops - these are just used in the tests
5. knitr & rmarkdown (not useful if you are using old style Sweave vignettes)

I think 1. kind of makes the dependencies = TRUE approach a non-starter for general use.

Re: @gaborcsardi this implementation does generate an error with informative message about the missing packages, but offering to install them isn't a bad idea though, maybe that is the best way to solve this problem...

[jimhester]

e4f1ece adds the a prompt to install the suggested packages if they are not installed, I think it will work well.

[hadley]

@gaborcsardi I think removing the Rcpp dependency from roxygen2 is going to be hard - it's just a much better tool for parsing stuff than R is. I'd rather push towards moving all the package install stuff out in a separate package.

[gaborcsardi]

@hadley I am not suggesting removing the C++ code, only the Rcpp wrapper. Rcpp is great, but the roxygen C++ code is short and seems straightforward without Rcpp, too.

Just an idea, not sure if it is worth the effort.

[jimhester]

jimhester@2db88ba adds a NOTE to news.

With e4f1ece if someone doesn't have roxygen2 or testthat installed when they run document() or test() respectively it will prompt them asking if they want to install it, so it should be pretty seamless for new users I think.

Another additional thing we could do would be to add installation prompts to setup() for roxygen2 and testthat. setup() is called for create() as well, so this would ensure users have both roxygen2 and testthat if they are writing a new package. I don't know how much that adds to the current functionality though, thoughts?

[jimhester]

This is now ready jimhester@d7c94be failed only because of GitHub rate limiting on Appveyor and contains only NEWS changes from jimhester@b4bc23e, which passed.

[hadley]

This looks good but I'm concerned that the version req is now recorded in two places, and the chances are that I'll forget to update one

[jimhester]

Hmm true, I can write a function to read the version number from the DESCRIPTION and use that is the default value of version for check_suggested().

[hadley]

Doesn't this also need a stop()? (i.e. if they say no)

[jimhester]

Yes! Fixed with jimhester@ab8bae8. Having the two stop() calls right after each other looks a little ugly, but modifying the conditional to avoid them would be just as bad in other ways.

[hadley]

Thanks!