[Rd] Recommended way to call/import functions from a Suggested package

[Hervé Pagès]

On 02/26/2013 05:28 PM, Simon Urbanek wrote:
>
> On Feb 26, 2013, at 6:48 PM, Hervé Pagès wrote:
>
>> On 02/26/2013 03:12 PM, Simon Urbanek wrote:
>>>
>>> On Feb 26, 2013, at 5:47 PM, Hervé Pagès wrote:
>>>
>>>> Hi,
>>>>
>>>> So MASS::huber(1:10) seems to do the job i.e. (1) loads the MASS
>>>> package (if it's installed), (2) does not pollute the search path,
>>>> (3) no 'R CMD check' warning if MASS is listed in Suggests,
>>>> and (4) descent error message if MASS is not installed:
>>>>
>>>>   > MASS::huber(1:10)
>>>>   Error in loadNamespace(name) : there is no package called ‘MASS’
>>>>
>>>
>>> But (4) is a problem - it may not fail without MASS since it is only suggested, that's why you need the try() ...
>>
>> Not everybody needs the try(). Some functions in my package won't be
>> able to return anything if the suggested package is not installed, so they will have to fail, preferably loudly rather than silently. A pretty common situation.
>>
>
> Hmm.. according to the docs that is not quite as intended: a package must work without "suggests" dependencies in the entirety. You can (conditionally) use suggested packages in datasets, examples or vignettes. Obviously, you could be tempted to hide this deficiency (functions failing without suggested packages) by not calling the functions that fail in your examples or tests, but I'd argue that is bypassing the design of "suggests".

Here is what the "Writing R Extensions" 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 (see Writing package
   vignettes), and *packages loaded in the body of functions*.

Then some examples are provided and they mostly focus on suggested
packages used in examples, tests or vignettes. I couldn't find
anywhere that ``a package must work without "suggests" dependencies
in the entirety''.

AFAIK there are many valid situations where one wants to provide
some additional functionalities in his/her package via suggested
packages. A typical example being a front-end function that supports
different back-ends defined in different packages: the default
back-end will generally be in Depends or Imports, the alternative
back-ends in Suggests. If the user specifies a back-end (thru
some argument passed to the front-end) that is not installed,
then s/he'll get an error.

I don't need to hide this deficiency by not calling the functions
that fail in my examples (or tests). I'll just call my front-end
without specifying an alternative back-end. Not a big deal if my
function generates a plot and if using the alternative back-end
would basically produce the same plot with only some small cosmetic
differences.

Cheers,
H.

>
>
>> Believe it or not, the discussion was not just about the recommended
>> way to call functions from the multicore package or another package
>> providing some kind of support for parallelization, where not having
>> it installed doesn't diminish the set of functionalities provided by
>> my package, only makes it slower.
>>
>
> I have no assumptions about what the author intended this functionality for, nor what you intend to use it for.
>
>
>>> The whole thread (which you omitted) was started because the usual if(require(...)) { .. } has an unwanted side-effect which the requestor did not want so the question was what does the job and that got settled before you joined in ...
>>
>> I didn't omit the thread: I actually read every answer including yours.
>> Are you claiming your solution is the recommended one?
>
> No - but as far as I can see it is in the spirit of the documentation which explicitly mentions if(require(..)) and further down talks about :: and Suggests - so putting 1 + 1 (conditionality and ::) has led me to devise what I suggested.
>
> Cheers,
> Simon
>
>
>> Thanks for
>> clarifying. Also as suggested by some posts in this thread, a
>> clarification in the official documentation would be nice.
>>
>
>
>
>
>> Thanks,
>> H.
>>
>>>
>>> Cheers,
>>> S
>>>
>>>
>>>
>>>
>>>> So is this recommendable or are there good reasons for stating in
>>>> the manual that "this approach is usually not recommended"? (In which
>>>> case it would be good to know what the recommended way is.)
>>>>
>>>> Thanks,
>>>> H.
>>>>
>>>>
>>>> On 02/25/2013 02:56 PM, Hadley Wickham wrote:
>>>>>> loadNamespaces loads but does not attach the package. Suggests: is enough to
>>>>>> quieten the warning with
>>>>>>
>>>>>> ~/tmp$ R --version
>>>>>> R Under development (unstable) (2013-02-21 r62017) -- "Unsuffered
>>>>>> Consequences"
>>>>>>
>>>>>> This is consistent with RShowDoc("R-exts") section 1.1.1
>>>>>>
>>>>>>    Namespaces accessed by the ‘::’ and ‘:::’ operators must be listed here,
>>>>>> or in ‘Suggests’ or ‘Enhances’ (see below).
>>>>>
>>>>> I guess that's changed since I last tried it.  (My reproducible
>>>>> example forgot to include MASS in the Suggests :/ )
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Hadley
>>>>>
>>>>
>>>> --
>>>> Hervé Pagès
>>>>
>>>> Program in Computational Biology
>>>> Division of Public Health Sciences
>>>> Fred Hutchinson Cancer Research Center
>>>> 1100 Fairview Ave. N, M1-B514
>>>> P.O. Box 19024
>>>> Seattle, WA 98109-1024
>>>>
>>>> E-mail: hpages at fhcrc.org
>>>> Phone:  (206) 667-5791
>>>> Fax:    (206) 667-1319
>>>>
>>>>
>>>
>>
>> --
>> Hervé Pagès
>>
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M1-B514
>> P.O. Box 19024
>> Seattle, WA 98109-1024
>>
>> E-mail: hpages at fhcrc.org
>> Phone:  (206) 667-5791
>> Fax:    (206) 667-1319
>>
>>
>

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319