On Sat, Sep 15, 2012 at 1:12 PM, Martin Morgan <mtmorgan@fhcrc.org> wrote:

> On 09/15/2012 09:00 AM, Henrik Bengtsson wrote:
>
>> On Sat, Sep 15, 2012 at 8:29 AM, Henrik Bengtsson <hb@biostat.ucsf.edu>
>> wrote:
>>
>>> Here's another example of this:
>>>
>>> http://bioconductor.org/**checkResults/devel/bioc-**
>>> LATEST/PANR/moscato1-checksrc.**html<http://bioconductor.org/checkResults/devel/bioc-LATEST/PANR/moscato1-checksrc.html>
>>>
>>> Question to BioC core: Why not sticking with the default
>>> _R_CHECK_FORCE_SUGGESTS_=**FALSE?
>>>
>>
>> My bad: It's TRUE by default
>>
>> <quote>
>> _R_CHECK_FORCE_SUGGESTS_
>> If true, give an error if suggested packages are not available.
>> Default: true (but false for CRAN submission checks).
>> </quote>
>>
>> (I've been using --as-cran to much lately).  Still standing by my
>> comments below though.
>>
>>    I see a suggested package as a
>>> package that is not required except in rare cases.  I also sometimes
>>>
>>
> The more usual scenario is that suggested packages are used during build
> or check but not by the installed package, e.g., suggested packages used in
> vignettes or perhaps unit tests. It's hard enough to write and support code
> that works consistently across platforms, so you're a brave person to want
> to write code that also supports different package configurations.
>
>
I'd like to support Martin's position here.  The WRE manual text:

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<http://cran.r-project.org/doc/manuals/R-exts.html#Writing-package-vignettes>),
and packages loaded in the body of functions. E.g., suppose an example 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.
Note that someone wanting to run the examples/tests/vignettes may not have
a suggested package available (and it may not even be possible to install
it for that platform), so it is helpful if the use of suggested packages is
made conditional *via* if(require(pkgname))).

IMHO a key virtue of the checking process is that it connects the checking
environment with the requirements of the checked package.  If I have an
image E of R that package p passes check on, then I am _reasonably
confident_ that when I try to run any example or vignette in p in E, I will
succeed.  There are several possible sources of concern.  First, I would
like to convert _reasonably confident_ to 100% confident.  I don't think we
know how to do this.  Second, sometimes when check fails, it signals a
"problem" with E, and sometimes a "problem" with p.  It would be nice for
developers to know which is the case, for any given check failure.  Again I
don't think we know exactly how to accomplish this.  However, I am pretty
sure that changing E in a systematic way to give developers "more
flexibility" by reducing check stringency against examples and vignettes
would be a major retrograde step.  If memory serves me, at least some of
this stringency was not even conceivable until Bioconductor development
practices took shape about 10 years ago.  This stringency provides
important benefits for the project as a whole and for module
interoperability, as imperfect as these may be at this time.  I would
suggest that any systematic changes be in the direction of more rather than
less stringency.


> _R_CHECK_FORCE_SUGGESTS_=TRUE restricts the universe of available packages
> to those on cran and Bioc (mostly), which have at least a modicum of
> testing and general availability that would seem to be desirable.
>
> Not meant to be the final word on the _R_CHECK_FORCE_SUGGESTS_ flag.
>
> Martin
>
>
>
>  use them to complement each other, e.g. part of my code prefer package
>>> A but if that doesn't exist it's fall back to use package B.  It's up
>>> to the developer to write examples()/system tests that don't generate
>>> R CMD check errors in these cases, and if they forget, then ...yes...
>>> R CMD check will generate an ERROR anyway.
>>>
>>
>> /Henrik
>>
>> PS. Yue, I don't it's not possible for the package to control these
>> flags/settings.
>>
>>
>>> /Henrik
>>>
>>> On Sat, Sep 15, 2012 at 7:40 AM, Yue Li <gorillayue@gmail.com> wrote:
>>>
>>>> Dear list,
>>>>
>>>> I just submitted a new package. It builds and checks OK on the Mac and
>>>> Linux servers but fails to build on the Windows server, namely 'mosacto1'.
>>>> The error says:
>>>>
>>>> * checking package dependencies ... ERROR
>>>> Package suggested but not available: 'multicore'
>>>>
>>>> The suggested packages are required for a complete check.
>>>> Checking can be attempted without them by setting the environment
>>>> variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
>>>>
>>>> But it seems that I can only set that environment variable
>>>> _R_CHECK_FORCE_SUGGESTS_ in ~/.R/check.Renviron on my local machine not on
>>>> the server. I wonder if anyone encountered the same problem when trying to
>>>> submit your package before? I apologize if the issue has been addressed in
>>>> some other posts that I failed to find it by Google.
>>>>
>>>> Thanks in advance,
>>>> Yue
>>>> ______________________________**_________________
>>>> Bioc-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>>>
>>>
>> ______________________________**_________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
>
> ______________________________**_________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>

	[[alternative HTML version deleted]]

