On Feb 27, 2013, at 12:54 AM, Hervé Pagès wrote:
> 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.
*alternative*, yes.
Cheers,
Simon
> 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: hpa...@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: hpa...@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: hpa...@fhcrc.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
