[Rd] Suggested dependencies in context of R CMD check

Duncan Murdoch murdoch.duncan at gmail.com
Tue Apr 5 01:01:29 CEST 2016


On 04/04/2016 7:12 PM, Paul Gilbert wrote:
>
>
> 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?

Supposing all dependencies are available, there are several ways to 
decide on pass vs fail.

  - You fail if your examples generate an error.
  - If you have saved example output, you fail if it doesn't match the 
old output.
  - You fail if your tests generate an error, or have different output 
than the optional saved output.

So what if some Suggested files are not available during testing?

The "fail on error" rule would be identical if the Suggested packages 
were missing.  Output of tests and examples will likely change, so if it 
were possible to test without Suggested packages, you'd need a way to 
indicate what changes are allowed.  (But most packages don't save test 
results and don't save example output anyway.)

Duncan Murdoch



More information about the R-devel mailing list