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: 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
