Suggested dependencies in context of R CMD check

On 04/04/2016 01:56 PM, Duncan Murdoch wrote:

On 04/04/2016 1:35 PM, Dirk Eddelbuettel wrote:

On 4 April 2016 at 07:25, Hadley Wickham wrote:
| On Sat, Apr 2, 2016 at 5:33 AM, Jan G?recki <J.Gorecki at wit.edu.pl>
wrote:
|
| In principle, I believe a package should pass R CMD check if no
| suggested packages are installed. However, since this is not currently

The relevant manual says

       The 'Suggests' field uses the same syntax as 'Depends' and lists
    packages that are not necessarily needed.  This includes packages used
    only in examples, tests or vignettes (*note Writing package
    vignettes::), and packages loaded in the body of functions.  E.g.,
    suppose an example(1) from package *foo* uses a dataset from package
    *bar*.  Then it is not necessary to have *bar* use *foo* unless one
    wants to execute all the examples/tests/vignettes: it is useful to
have
    *bar*, but not necessary.  Version requirements can be specified, and
    will be used by 'R CMD check'.

and later

     * All packages that are needed(2) to successfully run 'R CMD check'
       on the package must be listed in one of 'Depends' or 'Suggests' or
       'Imports'.  Packages used to run examples or tests conditionally
       (e.g. _via_ 'if(require(PKGNAME))') should be listed in 'Suggests'
       or 'Enhances'.  (This allows checkers to ensure that all the
       packages needed for a complete check are installed.)

| automatically checked, many packages will fail to cleanly pass R CMD
| check if suggested packages are missing.

I consider that to be a bug in those 'many packages'.  It essentially
takes
away the usefulness of having a Suggests: to provide a more fine-grained
dependency graph.

So I am with Jan here.

I think I agree with Jan, but not for the reason you state.

Suggests is useful even if "R CMD check" treats it as Depends, because
most users never need to run "R CMD check".  It allows them to use a
subset of the functionality of a package without installing tons of
dependencies.

I agree that packages that fail on examples when Suggested packages are
missing are broken.  (Using if (require()) to skip particular examples
isn't failing.)  It would be useful to be able to detect failure; I
don't think that's easy now with "R CMD check".  That's why you should
be able to run it with Suggested packages missing.

Perhaps I'm confused, it would not be the first time, but I have the
impression that some/all? of you are arguing for a different philosophy
around R CMD check and Suggests/Depends. But the current design is not
broken, it is working the way it has been advertised for many years now.
It provides a fine-grained dependency graph for end users, not
developers and testers. Being able to suggest packages for use in
testing, when they are not needed for regular use is a good thing. A
package failing R CMD check when the suggested packages are not
available is not a bug, it is a feature following the rules as they have
been designed. If you want to check a package then you need to install
things that are needed to check it. If R CMD check skipped testing
because suggested packages were not available then you will have many
packages not being tested properly, that is, lots of broken packages
passing R CMD check. (I've done this to myself sometimes using
if(require()).) There are situations where some testing needs to be
skipped, for example, license requirements and special databases, but
this needs to be done carefully, and my impression is that if(require())
provides most of what is necessary, sometimes along with environment
variables. Perhaps this is not elegant, but it does work and is not
difficult.

The ideal situation would be to be able to run all possible combinations
of missing Suggested packages, but that's probably far too slow to be a
default.

But how do you decide pass/fail when you do this? I think it will only
pass when all the suggested packages are available?